https://en.bitcoin.it/w/api.php?action=feedcontributions&user=Amincd&feedformat=atomBitcoin Wiki - User contributions [en]2024-03-19T02:48:33ZUser contributionsMediaWiki 1.30.0https://en.bitcoin.it/w/index.php?title=User_talk:Amincd&diff=60436User talk:Amincd2016-02-20T05:04:04Z<p>Amincd: </p>
<hr />
<div>I just wanted to thank you for taking the time to write https://en.bitcoin.it/w/index.php?title=Scalability_FAQ&curid=6428&diff=60396&oldid=60394 , which I do think improves the original section. --[[User:Harding|Harding]] ([[User talk:Harding|talk]]) 23:38, 15 February 2016 (UTC)<br />
<br />
::Thanks for the note! [[User:Amincd|Amincd]] ([[User talk:Amincd|talk]]) 05:04, 20 February 2016 (UTC)</div>Amincdhttps://en.bitcoin.it/w/index.php?title=Scalability_FAQ&diff=60398Scalability FAQ2016-02-15T04:55:04Z<p>Amincd: /* What is the short history of the block size limit? */ fixed typo</p>
<hr />
<div>Answers to commonly-asked questions and concerns about scaling Bitcoin, including “level 1” solutions such as increasing the block size and “level 2” solutions such as the proposed Lightning network.<br />
<br />
== Background ==<br />
<br />
Questions about how Bitcoin currently works (related to scaling) as well as questions about the technical terminology related to the scaling discussion.<br />
<br />
=== What is the short history of the block size limit? ===<br />
<br />
''Note: the software now called Bitcoin Core was previously simply called “Bitcoin”.<ref>[https://bitcoin.org/en/release/v0.9.0#rebranding-to-bitcoin-core Bitcoin Core 0.9.0 release notes], Bitcoin.org, 19 March 2014</ref> To avoid confusion with the Bitcoin system, we’ll use the Bitcoin Core name.''<br />
<br />
Bitcoin Core was initially released without an explicit block size limit. However, the code did limit network messages to a maximum of 32 MiB, setting an effective upper bound on block size.<ref>[https://bitcointalk.org/index.php?topic=68121 Earliest known Bitcoin code], <code>src/main.h:17</code></ref><br />
<br />
Around 15 July 2010, Satoshi Nakamoto changed Bitcoin Core’s mining code so that it wouldn’t create any blocks larger than 990,000 bytes.<ref>[https://github.com/bitcoin/bitcoin/commit/a30b56ebe76ffff9f9cc8a6667186179413c6349 Bitcoin Core commit a30b56e], Satoshi Nakamoto, 15 July 2010</ref><br />
<br />
Two months later on 7 September 2010, Nakamoto changed Bitcoin Core’s consensus rules to reject blocks larger than 1,000,000 bytes (1 megabyte) if their block height was higher than 79,400.<ref>[https://github.com/bitcoin/bitcoin/commit/8c9479c6bbbc38b897dc97de9d04e4d5a5a36730 Bitcoin Core commit 8c9479c], Satoshi Nakamoto, 7 September 2010</ref> (Block 79,400 was later produced on 12 September 2010.<ref>[https://www.biteasy.com/blockchain/blocks/000000000021d821ec06be7173f413690bc5c4bc648dfa70b3b6763236f055b7 Block height 79400], dated 12 September 2010</ref>)<br />
<br />
Neither the July nor the September commit message explains the reason for the limit, although the careful attempt to prevent a fork may indicate Nakamoto didn’t consider it an emergency.<br />
<br />
Nakamoto’s subsequent statements supported raising the block size at a later time<ref>[https://bitcointalk.org/index.php?topic=1347.msg15139#msg15139 Increasing the block size when needed], Satoshi Nakamoto, 3 October 2010</ref>, but he never publicly specified a date or set of conditions for the raise.<br />
<br />
Statements by Nakamoto in the summer of 2010 indicate he believed Bitcoin could scale to block sizes far larger than 1 megabyte. For example, on 5 August 2010, he wrote that "[W]hatever size micropayments you need will eventually be practical. I think in 5 or 10 years, the bandwidth and storage will seem trivial" and "[microtransactions on the blockchain] can become more practical ... if I implement client-only mode and the number of network nodes consolidates into a smaller number of professional server farms" <ref>[https://bitcointalk.org/index.php?topic=532.msg6306#msg6306 the number of network nodes consolidates into a smaller number of professional server farms]</ref>. <br />
<br />
These statements suggest that the intended purpose of the 1 megabyte limit was not to keep bandwidth and storage requirements for running a Bitcoin node low enough to be practical for personal computers and consumer-grade internet connections, and that the limit was intended to be lifted to accommodate greater demand for transactional capacity.<br />
<br />
=== What is this Transactions Per Second (TPS) limit? ===<br />
<br />
The current block size limit is 1,000,000 bytes (1 megabyte)<ref>[https://github.com/bitcoin/bitcoin/blob/41076aad0cbdfa4c4cf376e345114a5c29086f81/src/consensus/consensus.h#L10 <code>MAX_BLOCK_SIZE</code>], retrieved 2 July 2015</ref>, although a small amount of that space (such as the block header) is not available to store transactions.<ref>[https://bitcoin.org/en/developer-reference#serialized-blocks Block serialization description], Bitcoin.org Developer Reference</ref><br />
<br />
Bitcoin transactions vary in size depending on multiple factors, such as whether they’re spending single-signature inputs or a multiple signature inputs, and how many inputs and outputs they have.<br />
<br />
The simple way to calculate the number of Transactions Per Second (TPS) Bitcoin can handle is to divide the block size limit by the expected average size of transactions, divided by the average number of seconds between blocks (600). For example, if you assume average transactions are 250 bytes,<br />
<br />
<pre>6.6 TPS = 1,000,000 / 250 / 600</pre><br />
<br />
There seems to be general agreement that Bitcoin in 2015 can handle about 3 TPS with the current average size of transactions.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/007986.html Max TPS based on current average transaction size], Mike Hearn, 8 May 2015</ref><ref name="maxwell_not_proposing">[https://www.reddit.com/r/Bitcoin/comments/39yaod/bitcoinorg_position_on_hard_forks/cs7qz5c "No one proposing 3 TPS forever"], Gregory Maxwell, 15 June 2015</ref><br />
<br />
Both old estimates<ref>[[Scalability]], Bitcoin Wiki, retrieved 7 July<br />
2015</ref> and new estimates<ref name="garzik_bip" /> place the<br />
theoretical maximum at 7 TPS with current Bitcoin consensus rules<br />
(including the 1MB block size limit).<br />
<br />
=== What do devs mean by the scaling expressions O(1), O(n), O(n<sup>2</sup>), etc…? ===<br />
<br />
[https://en.wikipedia.org/wiki/Big_O_notation Big O notation] is a shorthand used by computer scientists to describe how well a system scales. Such descriptions are rough approximations meant to help predict potential problems and evaluate potential solutions; they are not usually expected to fully capture all variables.<br />
<br />
* '''O(1)''' means a system has roughly the same properties no matter how big it gets.<br />
* '''O(n)''' means that a system scales linearly: doubling the number of things (users, transactions, etc.) doubles the amount of work.<br />
* '''O(n<sup>2</sup>)''' means that a system scales quadratically : doubling (2x) the number of things quadruples (4x) the amount of work. Often written O(n^2) is places without convenient superscripts.<br />
* Additional examples may be found in the [https://en.wikipedia.org/wiki/Big_O_notation#Orders_of_common_functions Wikipedia article]<br />
<br />
The following subsections show cases where big O notation has been applied to the scaling Bitcoin transaction volume.<br />
<br />
==== O(1) block propagation ====<br />
<br />
Bitcoin Core currently relays unconfirmed transactions and then later relays blocks containing many of the same transactions. This redundant relay can be eliminated to allow miners to propagate large blocks very quickly to active network nodes, and would also significantly reduce miner need for peak bandwidth. Currently most miners use a network<ref name="block_relay_net">[http://bitcoinrelaynetwork.org/ Matt Corallo's block relay network]</ref> that is about 25x more efficient than stock Bitcoin Core<ref>[https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2#i-know-that-you-know IBLT design document], Gavin Andresen, 11 August 2014</ref> and almost equally as effective as O(1) block propagation for current block sizes.<br />
<br />
<br />
==== O(n<sup>2</sup>) network total validation resource requirements with decentralization level held constant ====<br />
<br />
[[File:On2_scaling_illustrated.png|thumb|right|visualization of O(n<sup>2</sup>) scaling]]<br />
<br />
While the validation effort required per full node simply grows in O(n), the combined validation effort of all nodes grows by O(n<sup>2</sup>) with decentralization being held constant. For a single node, it takes twice as many resources to process the transactions of twice as many users, while for all nodes it takes a combined four times as many resources to process the transactions of twice as many users assuming the number of full nodes increases in proportion to the number of users.<br />
<br />
Each on-chain Bitcoin transaction needs to be processed by each full node. If we assume that a certain percentage of users run full nodes (''n'') and that each user creates a certain number of transactions on average (''n'' again), then the network’s total resource requirements are <code>n<sup>2</sup> = n * n</code>. In short, this means that the aggregate cost of keeping all transactions on-chain quadruples each time the number of users doubles.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009199.html Total system cost], Dr. Adam Back, 28 June 2015</ref> For example,<br />
<br />
* Imagine a network starts with 100 users and 2 total nodes (a 2% ratio).<br />
<br />
* The network doubles in users to 200. The number of nodes also doubles to 4 (maintaining a 2% ratio of decentralized low-trust security). However, double the number of users means double the number of transactions, and each node needs to process ''every'' transaction---so each node now does double work with its bandwidth and its CPU. With double the number of nodes and double the amount of work per node, total work increases by four times.<br />
<br />
* The network doubles again: 400 users, 8 nodes (still 2% of total), and 4 times the original workload per node for a total of 16 times as much aggregate work as the original.<br />
<br />
* Another doubling: 800 users, 16 nodes (still 2%), and 8 times the original workload per node for a total of 64 times aggregate work as the original.<br />
<br />
* Another doubling: 1,600 users—sixteen times the original---with 32 nodes (still 2%), and 16 times the original workload per node. The aggregate total work done by nodes is 256 times higher than it was originally.<br />
<br />
===== Criticisms =====<br />
<br />
Emphasis on the total validation resource requirements is suggested by some individuals to be misleading, as they claim it obfuscates the growth of the supporting base of full nodes that the total validation resource effort is split amongst. The validation resource effort made by each individual full node increases at O(n), and critics say this is the only pertinent fact with respect to scaling. Some critics also point out that the O(n<sup>2</sup>) network total validation resource requirements claim is assuming decentralization must be held constant as the network scales, and that this is not a founding principle of Bitcoin.<br />
<br />
=== What’s the difference between on-chain and off-chain transactions? ===<br />
<br />
On-chain Bitcoin transactions are those that appear in the Bitcoin block chain. Off-chain transactions are those that transfer ownership of bitcoins without putting a transaction on the block chain.<br />
<br />
Common and proposed off-chain transactions include:<br />
<br />
* '''Exchange transactions:''' when you buy or sell bitcoins, the exchange tracks ownership in a database without putting data in the block chain. Only when you deposit or withdraw bitcoins does the transaction appear on the block chain.<br />
* '''Web wallet internal payments:''' many web wallets allow users of the service to pay other users of the same service using off-chain payments. For example, when one Coinbase user pays another Coinbase user.<br />
* '''Tipping services:''' most tipping services today, such as ChangeTip, use off-chain transactions for everything except deposits and withdrawals.<ref>[https://www.changetip.com/fees ChangeTip fees], retrieved 3 July 2015</ref><br />
* '''Payment channels:''' channels are started using one on-chain transaction and ended using a second on-chain transaction.<ref>[https://bitcoin.org/en/developer-guide#micropayment-channel Micropayment channels], Bitcoin.org Developer Guide</ref> In between can be an essentially unlimited number of off-chain transactions as small as a single satoshi (1/100,000,000th of a bitcoin). Payment channels include those that [https://bitcoinj.github.io/working-with-micropayments exist today] as well as proposed hub-and-spoke channels and the more advanced [http://lightning.network/ Lightning network].<br />
<br />
Approximately 90% to 99% of all bitcoin-denominated payments today are made off-chain.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008844.html Pure off-chain is a weak form of layer 2], Dr. Adam Back, 19 June 2015</ref><br />
<br />
=== What is a fee market? ===<br />
<br />
When you create a Bitcoin transaction, you have the option to pay a [[transaction fee]]. If your software is flexible, you can pay anything from zero fees (a free transaction) to 100% of the value of the transaction (spend-to-fees). This fee is comparable to a tip. The higher it is, the bigger the incentive of the miners to incorporate your transaction into the next block.<br />
<br />
When miners assemble a block, they are free to include whatever transactions they wish. They usually include as many as possible up to the maximum block size and then prioritize the transactions that pay the most fees per kilobyte of data.<ref name="fee_pri">[https://bitcointalk.org/index.php?topic=95837.0 Fee prioritization patch], Gavin Andresen, 26 July 2012</ref> This confirms higher-fee transactions before lower-fee transactions. If blocks become full on a regular basis, users who pay a fee that's too small will have to wait a longer and longer time for their transactions to confirm. At this point, a demand-driven fee market may arise where transactions that pay higher fees get confirmed significantly faster than transactions that pay low fees.<ref name="todd_coinwallet">[https://gist.github.com/petertodd/8e87c782bdf342ef18fb Comments on the CoinWallet.eu tx-flood stress-test], Peter Todd, 22 June 2015</ref><ref name="garzik_bip" /><br />
<br />
In a competitive market, prices are driven by supply and demand and the emerging equilibrium price asymptotically approaches marginal costs over time. However, the current version of Bitcoin limits the supply to 1 MB per block, only allowing demand to adjust. To establish a free market, one would need to come up with a mechanism that allows the number of included transactions per block to adjust dynamically as well. The design of such a mechanism, however, is not trivial. Simply allowing individual miners to include as many transactions as they want is problematic due to the externalities<ref name="exernality">[https://en.wikipedia.org/wiki/Externality Definition of externality], Wikipedia, 26 January 2016</ref> of including additional blocks and explained further in section [[#Should miners be allowed to decide the block size?|'should miners be allowed to decide the block size?']] .<br />
<br />
=== What is the most efficient way to scale Bitcoin? ===<br />
<br />
Remove its decentralization properties, specifically decentralized mining and decentralized full nodes. Mining wastes enormous amounts of electricity to provide a decentralized ledger and full nodes waste an enormous amount of bandwidth and CPU time keeping miners honest.<br />
<br />
If users instead decided to hand authority over to someone they trusted, mining and keeping miners honest wouldn’t be needed. This is how Visa, MasterCard, PayPal, and the rest of the centralized payment systems works—users trust them, and they have no special difficulty scaling to [[scalability|millions of transactions an hour]]. It’s very efficient; it isn’t decentralized.<br />
<br />
=== What is a hard fork, and how does it differ from other types of forks? ===<br />
<br />
The word fork is badly overloaded in Bitcoin development.<br />
<br />
* '''[[hardfork|Hard fork]]:''' a change to the system which is not backwards compatible. Everyone needs to upgrade or things can go wrong.<br />
* '''[[softfork|Soft fork]]:''' a change to the system which is backwards compatible as long as a majority of miners enforce it. Full nodes that don’t upgrade have their security reduced.<br />
* '''Chain fork:''' when there are two are more blocks at the same height on a block chain. This typically happens a few times a week by accident, but it can also indicate more severe problems.<br />
* '''[https://en.wikipedia.org/wiki/Fork_%28software_development%29 Software fork]:''' using the code from an open source project to create a different project.<br />
* '''[https://help.github.com/articles/fork-a-repo/ Git/GitHub fork]:''' a way for developers to write and test new features before contributing them to a project.<br />
<br />
(There are other types of software-related forks, but they don’t tend to cause as much confusion.)<br />
<br />
=== What are the block size soft limits? ===<br />
<br />
Bitcoin Core has historically come pre-configured to limit blocks it mines to certain sizes.<ref name="fee_pri" /> These “limits” aren’t restrictions placed on miners by other miners or nodes, but rather configuration options that help miners produce reasonably-sized blocks.<br />
<br />
Miners can change their soft limit size (up to 1 MB) using <code>-blockmaxsize=&lt;size&gt;</code><br />
<br />
Default soft limits at various times:<br />
<br />
* '''July 2012:''' <code>-blockmaxsize</code> option created and set to default 250 KB soft limit<ref>[https://github.com/bitcoin/bitcoin/commit/c555400ca134991e39d5e3a565fcd2215abe56f6 Bitcoin Core commit c555400], Gavin Andresen, 12 July 2012</ref><br />
* '''November 2013:''' Raised to 750KB<ref>[https://github.com/bitcoin/bitcoin/commit/ad898b40aaf06c1cc7ac12e953805720fc9217c0 Bitcoin Core commit ad898b40], Gavin Andresen, 27 November 2013</ref><br />
* '''June 2015:''' Raise to 1 MB suggested<ref>[https://github.com/bitcoin/bitcoin/pull/6231 Bitcoin Core pull #6231], Chris Wheeler, 4 June 2015</ref><br />
<br />
== General Block Size Increase Theory ==<br />
<br />
Questions about increasing the block size in general, not related to any<br />
specific proposal.<br />
<br />
==== Why are some people in favor of keeping the block size at 1 MB forever? ====<br />
<br />
It is commonly claimed<ref name="garzik_bip" /><ref>[https://epicenterbitcoin.com/podcast/082/ Epicenter Bitcoin podcast #82], Mike Hearn (interviewed), 8 June 2015</ref> that there are people opposed to ever raising the maximum block size limit, but no Bitcoin developers have suggested keeping the maximum block size at one megabyte forever.<ref name="maxwell_not_proposing" /><br />
<br />
All developers support raising the maximum size at some point<ref>[https://www.reddit.com/r/Bitcoin/comments/39kqzs/how_about_a_softfork_optin_blocksize_increase/cs5hj8l Nothing magic about 1MB], Dr. Adam Back, 13 June 2015</ref><ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008328.html Regarding size-independent new block propagation], Pieter Wuille, 28 May 2015</ref>—they just disagree about whether now is the correct time.<br />
<br />
==== Should miners be allowed to decide the block size? ====<br />
<br />
A block may include as little as a single transaction, so miners can always restrict block size. Letting miners choose the maximum block size is more problematic for several reasons:<br />
<br />
# '''Miners profit, others pay the cost:''' bigger blocks earn miners more fees, but miners don’t need to store those blocks for more than a few days.<ref>[https://github.com/bitcoin/bitcoin/pull/5863 Bitcoin Core pull #5863 adding pruning functionality], Suhas Daftuar et al., 6 March 2015</ref> Other users who want full validation security, or who provide services to lightweight wallets, pay the costs of downloading and storing those larger blocks.<br />
# '''Bigger miners can afford more bandwidth:''' each miner needs to download every transaction that will be included in block,<ref name="maxwell_correcting_assumptions" /> which means that they all need to pay for high-speed connections. However, a miner with 8.3% of total hash rate can take that cost out of the about 300 BTC they make a day, while a miner with only 0.7% of total hash rate has to take that cost out of only 25 BTC a day. This means bigger miners may logically choose to make bigger blocks even though it may further centralize mining.<br />
# '''Centralized hardware production:''' only a few companies in the world produce efficient mining equipment, and many of them have chosen to stop selling to the public.<ref>[http://blogs.wsj.com/venturecapital/2014/09/05/for-kncminer-time-to-forget-selling-bitcoin-machines-to-at-home-miners/ KnCMiner to stop selling to home miners], Wall Street Journal, Yuliya Chernova, 5 September 2014</ref> This prevents ordinary Bitcoin users from participating in the process even if they were willing to pay for mining equipment.<br />
# '''Voting by hash rate favors larger miners:''' voting based on hash rate allows the current hash rate majority (or super-majority) to enforce conditions on the minority. This is similar to a lobby of large businesses being able to get laws passed that may hurt smaller businesses.<ref>[https://www.reddit.com/r/Bitcoin/comments/39kzyt/draft_bip_100_soft_fork_block_size_increase/cs5gvak Miners choosing the block size limit is ill-advised], Meni Rosenfeld, 13 June 2015</ref><br />
# '''Miners may not care about users:''' this was demonstrated during the [[July 2015 Forks]] where even after miners lost over $50,000 USD in income from mining invalid chains, and even after they were told that long forks harm users, they continued to mine improperly.<ref>[https://bitcointalk.org/index.php?topic=700411.msg11790734#msg11790734 Intention to continue SPV mining], Wang Chun, 4 July 2015</ref><br />
<br />
However, there are also possible justifications for letting miners choose the block size:<br />
<br />
# '''Authenticated participants:''' miners are active participants in Bitcoin, and they can prove it by adding data to the blocks they create.<ref>[https://bitcoin.org/en/developer-reference#term-coinbase-field Coinbase field], Bitcoin.org Developer Reference</ref> It is much harder to prove people on Reddit, BitcoinTalk, and elsewhere are real people with an active stake in Bitcoin.<br />
# '''Bigger blocks may cost miners:''' small miners and poorly-connected miners are at a disadvantage if larger blocks are produced<ref name="wuille_centralization" />, and even large and well-connected miners may find that large blocks reduce their profit percentage if the cost of bandwidth rises too high or their stale rate increases.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008355.html F2Pool block size concerns], Chun Wang, 29 May 2015</ref><br />
<br />
==== How could a block size increase affect user security? ====<br />
<br />
Bitcoin’s security is highly dependent on the number of active users who protect their bitcoins with a full node like Bitcoin Core. The more active users of full nodes, the harder it is for miners to trick users into accepting fake bitcoins or other frauds.<ref>[https://medium.com/@lopp/bitcoin-nodes-how-many-is-enough-9b8e8f6fd2cf Bitcoin nodes: how many is enough?], Jameson Lopp, 7 June 2015</ref><br />
<br />
Full nodes need to download and verify every block, and most nodes also store blocks plus relay transactions, full blocks, and filtered blocks to other users on the network. The bigger blocks become, the more difficult it becomes to do all this, so it is expected that bigger blocks will both reduce the number of users who currently run full nodes and suppress the number of users who decide to start running a full node later.<ref>[https://www.reddit.com/r/Bitcoin/comments/3bae2d/amir_taaki_on_raising_the_block_size_a_lot_of/cslcgmw Block size increases-only will create problems], Dr. Adam Back, 28 June 2015</ref><br />
<br />
In addition, full blocks may increase mining centralization<ref name="wuille_centralization" /> at a time when mining is already so centralized that it makes it easy to reverse transactions which have been confirmed multiple times.<ref>[http://bitcoin.stackexchange.com/questions/32562/when-to-worry-about-1-confirmation-payments/32564#32564 When to worry about one-confirmation payments], David A. Harding, 17 November 2014</ref><br />
<br />
==== How could larger blocks affect proof-of-work (POW) security? ====<br />
<br />
Proof of work security is dependent on how much money miners spend on mining equipment. However, to effectively mine blocks, miners also need to spend money on bandwidth to receive new transactions and blocks created by other miners; CPUs to validate received transactions and blocks; and bandwidth to upload new blocks. These additional costs don’t directly contribute to POW security.<ref name="maxwell_correcting_assumptions">[https://www.reddit.com/r/Bitcoin/comments/39tgno/letting_miners_vote_on_the_maximum_block_size_is/cs6rek5 Correcting wrong assumptions about mining], Gregory Maxwell, 15 June 2015</ref><br />
<br />
As block sizes increase, the amount of bandwidth and CPU required also increases. If block sizes increase faster than the costs of bandwidth and CPU decrease, miners will have less money for POW security relative to the gross income they earn.<br />
<br />
In addition, larger blocks have a higher risk of becoming stale (orphaned)<ref name="rusty_dsl" />, which directly correlates to lost POW security. For example, if the network average stale rate is 10%, then 10% of POW performed isn't protecting transactions on the block chain.<br />
<br />
Conversely, larger blocks that result in a lower per transaction fee can increase the demand for on-chain transactions, and result in total transaction fees earned by miners increasing despite a lower average transaction fee. This would increase network security by increasing the revenue that supports Proof of Work generation. <br />
<br />
Without an increase in the block size from 1 megabyte, Bitcoin needs $1.50 worth of BTC paid in fees per transaction once block subsidies disappear to maintain current mining revenue and economic expenditure on network security. The required fee per transaction for maintaining current economic expenditure levels once the subsidy disappears decreases as the block size, and with it the maximum on-chain transaction throughput, increases. <br />
<br />
As a result of the sensitivity of demand to price increases, growth in the Bitcoin economy, and thus growth in the fees paid to secure the Bitcoin network, could be stunted if the block size is not allowed to increase sufficiently.<br />
<br />
=== What happens if blocks aren't big enough to include all pending transactions? ===<br />
<br />
This is already the case more often than not<ref>[http://statoshi.info/dashboard/db/transactions?from=1433297061121&to=1435889061123 Statoshi.info mempool queue June to July 2015]</ref>, so we know that miners will simply queue transactions. The transactions eligible for block inclusion that pay the highest fee per kilobyte will be confirmed earlier than transactions that pay comparatively lower fees.<ref name="fee_pri" /><br />
<br />
Basic economic theory tells us that increases in price reduce economic demand, ceteris paribus. Assuming that larger blocks would not cause a loss of demand for on-chain transaction processing due to a perceived loss of the network's decentralization and censorship resistance, blocks that are too small to include all pending transactions will result in demand for on-chain transaction processing being less than it would be if blocks were large enough include all pending transactions.<br />
<br />
What happens from there is debated:<br />
<br />
* BitcoinJ lead developer Mike Hearn believes there would be “crashing nodes, a swelling transaction backlog, a sudden spike in double spending, [and] skyrocketing fees.”<ref>[https://medium.com/@octskyward/crash-landing-f5cc19908e32 Crash Landing], Mike Hearn, 7 May 2015</ref><br />
* Bitcoin Foundation chief scientist Gavin Andresen believes that the “average transaction fee paid will rise, people or applications unwilling or unable to pay the rising fees will stop submitting transactions, [and] people and businesses will shelve plans to use Bitcoin, stunting growth and adoption.” <ref>[https://github.com/bitcoin/bitcoin/pull/6341 Bitcoin Core pull #6341], Gavin Andresen, 26 June 2015</ref><br />
* Bitcoin Core developer Pieter Wuille replies to Andresen’s comment above: “Is it fair to summarize this as ‘Some use cases won’t fit any more, people will decide to no longer use the blockchain for these purposes, and the fees will adapt.’? I think that is already happening […] I don’t think we should be afraid of this change or try to stop it.” <ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009098.html The need for larger blocks], Pieter Wuille, 26 June 2015</ref><br />
* Bitcoin Core developer Jeff Garzik writes, "as blocks get full and the bidding war ensues, the bitcoin user experience rapidly degrades to poor. In part due to bitcoin wallet software’s relative immaturity, and in part due to bitcoin’s settlement based design, the end user experience of their transaction competing for block size results in erratic, and unpredictably extended validation times."<ref name="garzik_bip" /><br />
<br />
== Specific Scaling Proposals ==<br />
<br />
=== Andresen-Hearn Block Size Increase Proposals ===<br />
<br />
Questions about the series of related proposals by Gavin Andresen and Mike Hearn to use a hard fork to raise the maximum block size, thereby allowing miners to include more on-chain transactions. As of July 2015, the current focus is [https://github.com/bitcoin/bips/pull/163 BIP101].<br />
<br />
==== What is the major advantage of this proposal? ====<br />
<br />
''Bitcoin can support many more users.'' Assuming earliest possible adoption, 250 bytes per on-chain transaction, 144 blocks per day, and 2 transaction a day per user, Bitcoin can support about,<br />
<br />
* 288,000 users in 2015<br />
* 2,304,000 users in 2016 (800% increase)<br />
* 4,608,000 in 2018 (1,600%)<br />
* 9,216,000 in 2020 (3,200%)<br />
* 18,432,000 in 2022 (6,400%)<br />
* 36,864,000 in 2024 (12,800%)<br />
* 73,728,000 in 2026 (25,600%)<br />
* 147,456,000 in 2028 (51,200%)<br />
* 294,912,000 in 2030 (102,400%)<br />
* 589,824,000 in 2032 (204,800%)<br />
* 1,179,648,000 in 2034 (409,600%<br />
* 2,359,296,000 in 2036 (819,200%)<br />
<br />
==== What is the major disadvantage of this proposal? ====<br />
<br />
''The total cost of remaining decentralized will be high.'' Assuming earliest possible adoption and that the ratio of total users to full node operators remains the same as today, the total estimated amount of work necessary to maintain the decentralized system under the [[#O.28n2.29_network_total_validation_resource_requirements|O(<sup>2</sup>) scaling model]] will be,<br />
<br />
* 100% of today’s work in 2015<br />
* 6,400% in 2016<br />
* 25,600% in 2018<br />
* 102,400% in 2020<br />
* 409,600% in 2022<br />
* 1,638,400% in 2024<br />
* 6,553,600% in 2026<br />
* 26,214,400% in 2028<br />
* 104,857,600% in 2030<br />
* 419,430,400% in 2032<br />
* 1,677,721,600% in 2034<br />
* 6,710,886,400% in 2036<br />
<br />
For example, if the total amount spent on running full nodes today (not counting mining) is $100 thousand per year, the estimated cost for the same level of decentralization in 2036 will be $6.7 trillion per year if validation costs stay the same. (They'll certainly go down, but algorithmic and hardware improvements probably won't eliminate an approximate 6,710,886,400% cost increase.)<br />
<br />
==== What are the dangers of the proposed hard fork? ====<br />
<br />
Under the current proposal, 75% of miners must indicate that they agree to accept blocks up to 8 MB in size.<ref name="bip101">[https://github.com/bitcoin/bips/pull/163 BIP101], Gavin Andresen, 24 June 2016</ref> After the change goes into effect, if any miner creates a block larger than 1 MB, all nodes which have not upgraded yet will reject the block.<ref>[https://bitcoin.org/en/developer-guide#consensus-rule-changes Consensus rule changes], Bitcoin.org Developer Guide</ref><br />
<br />
If all full nodes have upgraded, or very close to all nodes, there should be no practical effect. If a significant number of full nodes have not upgraded, they will continue using a different block chain than the upgraded users, with the following consequences:<br />
<br />
* Bitcoins received from before the fork can be spent twice, once on both sides of the fork. This creates a high double spend risk.<br />
* Bitcoins received after the fork are only guaranteed to be spendable on the side of the fork they were received on. This means some users will have to lose money to restore Bitcoin to a single chain.<br />
<br />
Users of hosted wallets (Coinbase, BlockChain.info, etc.) will use whatever block chain their host chooses. Users of lightweight P2P SPV wallets will use the [[Thin Client Security|longest chain they know of]], which may not be the actual longest chain if they only connect to nodes on the shorter chain. Users of non-P2P SPV wallets, like Electrum, will use whatever chain is used by the server they connect to.<br />
<br />
If a bad hard fork like this happens, it will likely cause large-scale confusion and make Bitcoin very hard to use until the situation is resolved.<br />
<br />
==== What is the deployment schedule for BIP 101? ====<br />
<br />
* The patch needs to be accepted into Bitcoin Core, Bitcoin XT, or both.<br />
* If accepted into Bitcoin Core, miners using that software will need to upgrade (this probably requires a new released version of Bitcoin Core). If accepted only into Bitcoin XT, miners will need to switch to using XT.<br />
* After 75% of miners have upgraded, 8MB blocks will become allowed at the the latest of (1) 11 January 2016 or (2) two weeks after the 75% upgrade threshold.<ref name="bip101" /><br />
* After the effective date has passed, any miner may create a block larger than 8MB. When a miner does this, upgraded full nodes will accept that block and non-upgraded full nodes will reject it, forking the network.<ref name="bip101" /> See [[#What_are_the_dangers_of_the_proposed_hard_fork.3F|hard fork dangers]] for what his might mean.<br />
<br />
==== Will miners go straight from 1 MB blocks to 8 MB blocks? ====<br />
<br />
That would be highly unlikely. Uploading an 8 MB block currently takes significantly more time than uploading a 1 MB block<ref name="rusty_dsl">[http://rusty.ozlabs.org/?p=509 Mining on a home DSL connection test results], Rusty Russell, 19 June 2015</ref>, even with the roughly 25x reduction in size available from use of Matt Corallo’s block relay network.<ref name="block_relay_net" /><br />
<br />
The longer it takes to upload a block, the higher the risk it will become a stale block—meaning the miner who created it will not receive the block subsidy or transaction fees (currently about 25 BTC per block).<br />
<br />
However, if technology like Invertible Bloom Lookup Tables (IBLTs) is deployed and found to work as expected<ref name="iblt">[https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2 O(1) block propagation], Gavin Andresen, 8 August 2014</ref>, or if mining [[#What_is_the_most_efficient_way_to_scale_Bitcoin.3F|centralizes further]], adding additional transactions may not have a significant enough cost to discourage miners from creating full blocks. In that case, blocks will be filled as soon as there are enough people wanting to make transactions paying the default relay fee<ref>[https://github.com/bitcoin/bitcoin/pull/3305 Bitcoin Core pull #3305 dropping default fees], Mike Hearn, 22 November 2013</ref> of 0.00001000 BTC/kilobyte.<br />
<br />
==== What tests have been performed related to this proposal? ====<br />
<br />
* '''20MB block processing''' (Gavin Andresen) “if we increased the maximum block size to 20 megabytes tomorrow, and every single miner decided to start creating 20MB blocks and there was a sudden increase in the number of transactions on the network to fill up those blocks… the 0.10.0 version of [Bitcoin Core] would run just fine.”<ref>[http://gavintech.blogspot.com/2015/01/twenty-megabytes-testing-results.html Twenty megabyte block testing], Gavin Andresen, 20 January 2015</ref> (ellipses in original)<br />
* '''Mining &amp; relay simulation''' (Gavin Andresen) “if blocks take 20 seconds to propagate, a network with a miner that has 30% of the hashing power will get 30.3% of the blocks.”<ref>[http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners Are bigger blocks better for bigger miners?], Gavin Andresen, 22 May 2015</ref><br />
* '''Mining on a home DSL connection''' (Rusty Russell) “Using the rough formula of 1-exp(-t/600), I would expect orphan rates of 10.5% generating 1MB blocks, and 56.6% with 8MB blocks; that’s a huge cut in expected profits.”<ref name="rusty_dsl" /><br />
* '''Mining centralization pressure''' (Pieter Wuille) “[This] does very clearly show the effects of larger blocks on centralization pressure of the system.”<ref name="wuille_centralization">[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008581.html Mining centralization pressure from non-uniform propagation speed], Pieter Wuille, 12 June 2015</ref><br />
<br />
<br />
=== Garzik Miner Block Size Voting Proposal (AKA BIP100) ===<br />
<br />
''Note, BIP 100 is the marketing name for this proposal. No BIP number<br />
has yet been publicly requested, and the number assigned is unlikely to<br />
be 100.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-May/005756.html<br />
Prenumbered BIP naming], Gregory Maxwell, 12 May 2014</ref>''<br />
<br />
Questions related to Jeff Garzik's proposal<ref name="garzik_bip">[http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf Draft BIP: decentralized economic policy], Jeff Garzik, 12 June 2015 (revised 15 June 2015)</ref> to allow miners to vote on raising and lowering the maximum block size.<br />
<br />
==== What does this proposal do? ====<br />
<br />
# It creates a one-time hard fork that does not automatically change the maximum block size.<br />
<br />
# It allows miners to vote to increase or decrease the maximum block size within the range of 1MB to 32MB. These changes are neither hard forks nor soft forks, but simply rules that all nodes should know about after the initial hard fork.<br />
<br />
==== Does it reduce the risk of a hard fork? ====<br />
<br />
Hard forks are most dangerous when they're done without strong<br />
consensus.<ref name="garzik_bip" /><ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008779.html Consensus changes are not about making a change to the software],<br />
Pieter Wuille, 18 June 2015</ref><br />
<br />
If Garzik's proposal gains strong consensus, it will be as safe as possible<br />
for a hard fork and it will allow increasing the block size up to 32 MB<br />
without any additional risk of a fork.<br />
<br />
==== Why is it limited to 32 megabytes? ====<br />
<br />
According to the draft BIP, "the 32 MB hard fork is largely coincidental -- a whole network upgrade at 32 MB was likely needed anyway."<br />
<br />
=== Lightning Network ===<br />
<br />
Questions related to using the proposed [http://lightning.network/ Lightning network] as a way to scale the number of users Bitcoin can support.<br />
<br />
==== How does transaction security differ from that of Bitcoin? ====<br />
<br />
Transactions on the proposed Lightning network use Bitcoin transactions exclusively to transfer bitcoins<ref name="russell_lightning1">[http://rusty.ozlabs.org/?p=450 Lightning Networks: Part I], Rusty Russell, 30 March 2015</ref>, and so the same security as regular Bitcoin transactions is provided when both a Lightning hub and client are cooperating.<br />
<br />
When a Lightning hub or client refuses to cooperate with the other (maybe because they accidentally went offline), the other party can still receive their full 100% bitcoin balance by closing the payment channel—but they must first wait for a defined amount of time mutually chosen by both the hub and client.<ref>[http://rusty.ozlabs.org/?p=462 Lightning Networks: Part II], Rusty Russell, 1 April 2015</ref><br />
<br />
If one party waits too long to close the payment channel, the other party may be able to steal bitcoins. However, it is possible to delegate the task of closing the channel in an emergency to an unlimited number of hubs around the Internet, so closing the channel on time should be easy.<ref name="russell_lightning4">[http://rusty.ozlabs.org/?p=477 Lightning Networks: Part IV], Rusty Russell, 8 April 2015</ref><br />
<br />
In summary, provided that payment channels are closed on time, the worst that can happen to users is that they may have to wait a few weeks for a channel to fully close before spending the bitcoins they received from it. Their security is otherwise the same as with regular Bitcoin.<br />
<br />
For Lightning hubs, security is slightly worse in the sense that they need to keep a potentially-large amount of funds in a hot wallet<ref name="lightning_paper">[http://lightning.network/lightning-network-paper-DRAFT-0.5.pdf Lightning Network (Draft 0.5)], Section 6.3: Coin Theft via Hacking, Joseph Poon and Thaddeus Dryja</ref>, so they can’t take advantage of the anti-hacking protection offered by cold wallets. Otherwise, Lightning hubs have the same security as clients.<br />
<br />
==== When will Lightning be ready for use? ====<br />
<br />
Lightning requires a basic test implementation (work underway<ref>[https://lists.blockstream.com/pipermail/lightning-dev/2015-June/000018.html Lightning first steps], Rusty Russell, 13 June 2015</ref>), several soft-fork changes to the Bitcoin protocol (work underway<ref>[https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65: CheckLockTimeVerify], Peter Todd, 1 October 2014</ref><ref>[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68: Consensus-enforced transaction replacement], Mark Friedenbach, 28 May 2015</ref>, and wallets need to be updated to support the Lightning network protocol.<ref name="russell_lightning4" /><br />
<br />
Dr. Adam Back has said, "I expect we can get something running inside a year."<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009242.html Reply to Andresen regarding Lightning], Dr. Adam Back, 28 June 2015</ref><br />
<br />
==== Doesn’t Lightning require bigger blocks anyway? ====<br />
<br />
Lightning is block-size neutral. It requires one on-chain transaction to open a channel between a hub and a client, and one on-chain transaction to close a channel.<ref name="russell_lightning1" /> In between it can support an unlimited number of transactions between anyone on the Lightning network.<ref name="lightning_paper" /><br />
<br />
Using the numbers from the Lightning presentation<ref name="lightning_slides">[http://lightning.network/lightning-network.pdf Lightning presentation], Joseph Poon, 23 February 2015</ref>, if people open and close a plausible two channels a year, Lightning can support about 52 million users with the current one-megabyte limit—and each user can make an unlimited number of transactions. Currently, assuming people make an average of only two Bitcoin transactions a day, basic Bitcoin can support only 288,000 users.<br />
<br />
Under these assumptions, Lightning is 180 times (17,900%) more efficient than basic Bitcoin.<br />
<br />
Presumably, if around 30 million people are using Bitcoin via Lightning so that capacity is called into question, it will not be difficult to find consensus to double the block size to two megabytes and bring user capacity up to 105 million. The same goes for later increases to 200 million (4MB), 400 million (8MB), 800 million (16MB), 1.6 billion (32 MB), 3.2 billion (64MB), and all 7 billion living humans (133MB). In each case, all Lightning network participants get unlimited transactions to the other participants.<br />
<br />
For basic Bitcoin to scale to just 2 transactions a day for 7 billion people would require 24-gigabyte blocks.<ref name="lightning_slides" /><br />
<br />
=== Sidechains ===<br />
<br />
==== Real quick, what are sidechains? ====<br />
<br />
Block chains that are separate from Bitcoin’s block chain, but which allow you to receive and spend bitcoins using a two-way peg (2WP).<ref name="sidechains_paper">[https://www.blockstream.com/sidechains.pdf Sidechains paper], Adam Back et al., 22 October 2014</ref> (Although a sidechain can never be more secure than the Bitcoin block chain.<ref>[https://www.reddit.com/r/Bitcoin/comments/39r85g/sidechain_hate/cs5spbg Security limitations of pegged chains], Gregory Maxwell, 14 June 2015</ref>)<br />
<br />
==== Are sidechains a scaling option? ====<br />
<br />
No. Sidechains have the same fundamental scaling problems as Bitcoin does. Moving some transactions to sidechains simply moves some problems elsewhere on the network—the total difficulty of the problem remains the same.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008617.html Sidechains not a direct means for solving any of the scaling problems Bitcoin has], Pieter Wuille, 13 June 2015</ref><br />
<br />
==== But couldn’t I create a sidechain that had 100 GB blocks? ====<br />
<br />
Certainly, sidechain code is open source<ref>[https://github.com/ElementsProject/elements Elements Project]</ref>—so you can create your own sidechain. But you’d still have the difficulty of finding people who are willing to validate 100 GB blocks with their own full nodes.<br />
<br />
==== Do sidechains require a hard fork? ====<br />
<br />
No. Federated sidechains, such as have already been implemented<ref>[https://github.com/ElementsProject/elements/tree/alpha Elements Alpha]</ref>, don’t require any changes to the Bitcoin consensus rules. Merged-mined sidechains, which have not been implemented yet, do require a backwards-compatible soft fork in order to transfer funds between Bitcoin and the sidechain.<ref name="sidechains_paper" /><br />
<br />
== References ==<br />
<references /></div>Amincdhttps://en.bitcoin.it/w/index.php?title=Scalability_FAQ&diff=60397Scalability FAQ2016-02-14T18:36:57Z<p>Amincd: /* Criticisms */</p>
<hr />
<div>Answers to commonly-asked questions and concerns about scaling Bitcoin, including “level 1” solutions such as increasing the block size and “level 2” solutions such as the proposed Lightning network.<br />
<br />
== Background ==<br />
<br />
Questions about how Bitcoin currently works (related to scaling) as well as questions about the technical terminology related to the scaling discussion.<br />
<br />
=== What is the short history of the block size limit? ===<br />
<br />
''Note: the software now called Bitcoin Core was previously simply called “Bitcoin”.<ref>[https://bitcoin.org/en/release/v0.9.0#rebranding-to-bitcoin-core Bitcoin Core 0.9.0 release notes], Bitcoin.org, 19 March 2014</ref> To avoid confusion with the Bitcoin system, we’ll use the Bitcoin Core name.''<br />
<br />
Bitcoin Core was initially released without an explicit block size limit. However, the code did limit network messages to a maximum of 32 MiB, setting an effective upper bound on block size.<ref>[https://bitcointalk.org/index.php?topic=68121 Earliest known Bitcoin code], <code>src/main.h:17</code></ref><br />
<br />
Around 15 July 2010, Satoshi Nakamoto changed Bitcoin Core’s mining code so that it wouldn’t create any blocks larger than 990,000 bytes.<ref>[https://github.com/bitcoin/bitcoin/commit/a30b56ebe76ffff9f9cc8a6667186179413c6349 Bitcoin Core commit a30b56e], Satoshi Nakamoto, 15 July 2010</ref><br />
<br />
Two months later on 7 September 2010, Nakamoto changed Bitcoin Core’s consensus rules to reject blocks larger than 1,000,000 bytes (1 megabyte) if their block height was higher than 79,400.<ref>[https://github.com/bitcoin/bitcoin/commit/8c9479c6bbbc38b897dc97de9d04e4d5a5a36730 Bitcoin Core commit 8c9479c], Satoshi Nakamoto, 7 September 2010</ref> (Block 79,400 was later produced on 12 September 2010.<ref>[https://www.biteasy.com/blockchain/blocks/000000000021d821ec06be7173f413690bc5c4bc648dfa70b3b6763236f055b7 Block height 79400], dated 12 September 2010</ref>)<br />
<br />
Neither the July nor the September commit message explains the reason for the limit, although the careful attempt to prevent a fork may indicate Nakamoto didn’t consider it an emergency.<br />
<br />
Nakamoto’s subsequent statements supported raising the block size at a later time<ref>[https://bitcointalk.org/index.php?topic=1347.msg15139#msg15139 Increasing the block size when needed], Satoshi Nakamoto, 3 October 2010</ref>, but he never publicly specified a date or set of conditions for the raise.<br />
<br />
Statements by Nakamoto in the summer of 2010 indicate he believed Bitcoin could scale to block sizes far larger 1 megabyte. For example, on 5 August 2010, he wrote that "[W]hatever size micropayments you need will eventually be practical. I think in 5 or 10 years, the bandwidth and storage will seem trivial" and "[microtransactions on the blockchain] can become more practical ... if I implement client-only mode and the number of network nodes consolidates into a smaller number of professional server farms" <ref>[https://bitcointalk.org/index.php?topic=532.msg6306#msg6306 the number of network nodes consolidates into a smaller number of professional server farms]</ref>. <br />
<br />
These statements suggest that the intended purpose of the 1 megabyte limit was not to keep bandwidth and storage requirements for running a Bitcoin node low enough to be practical for personal computers and consumer-grade internet connections, and that the limit would be lifted to accommodate greater demand for transactional capacity.<br />
<br />
=== What is this Transactions Per Second (TPS) limit? ===<br />
<br />
The current block size limit is 1,000,000 bytes (1 megabyte)<ref>[https://github.com/bitcoin/bitcoin/blob/41076aad0cbdfa4c4cf376e345114a5c29086f81/src/consensus/consensus.h#L10 <code>MAX_BLOCK_SIZE</code>], retrieved 2 July 2015</ref>, although a small amount of that space (such as the block header) is not available to store transactions.<ref>[https://bitcoin.org/en/developer-reference#serialized-blocks Block serialization description], Bitcoin.org Developer Reference</ref><br />
<br />
Bitcoin transactions vary in size depending on multiple factors, such as whether they’re spending single-signature inputs or a multiple signature inputs, and how many inputs and outputs they have.<br />
<br />
The simple way to calculate the number of Transactions Per Second (TPS) Bitcoin can handle is to divide the block size limit by the expected average size of transactions, divided by the average number of seconds between blocks (600). For example, if you assume average transactions are 250 bytes,<br />
<br />
<pre>6.6 TPS = 1,000,000 / 250 / 600</pre><br />
<br />
There seems to be general agreement that Bitcoin in 2015 can handle about 3 TPS with the current average size of transactions.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/007986.html Max TPS based on current average transaction size], Mike Hearn, 8 May 2015</ref><ref name="maxwell_not_proposing">[https://www.reddit.com/r/Bitcoin/comments/39yaod/bitcoinorg_position_on_hard_forks/cs7qz5c "No one proposing 3 TPS forever"], Gregory Maxwell, 15 June 2015</ref><br />
<br />
Both old estimates<ref>[[Scalability]], Bitcoin Wiki, retrieved 7 July<br />
2015</ref> and new estimates<ref name="garzik_bip" /> place the<br />
theoretical maximum at 7 TPS with current Bitcoin consensus rules<br />
(including the 1MB block size limit).<br />
<br />
=== What do devs mean by the scaling expressions O(1), O(n), O(n<sup>2</sup>), etc…? ===<br />
<br />
[https://en.wikipedia.org/wiki/Big_O_notation Big O notation] is a shorthand used by computer scientists to describe how well a system scales. Such descriptions are rough approximations meant to help predict potential problems and evaluate potential solutions; they are not usually expected to fully capture all variables.<br />
<br />
* '''O(1)''' means a system has roughly the same properties no matter how big it gets.<br />
* '''O(n)''' means that a system scales linearly: doubling the number of things (users, transactions, etc.) doubles the amount of work.<br />
* '''O(n<sup>2</sup>)''' means that a system scales quadratically : doubling (2x) the number of things quadruples (4x) the amount of work. Often written O(n^2) is places without convenient superscripts.<br />
* Additional examples may be found in the [https://en.wikipedia.org/wiki/Big_O_notation#Orders_of_common_functions Wikipedia article]<br />
<br />
The following subsections show cases where big O notation has been applied to the scaling Bitcoin transaction volume.<br />
<br />
==== O(1) block propagation ====<br />
<br />
Bitcoin Core currently relays unconfirmed transactions and then later relays blocks containing many of the same transactions. This redundant relay can be eliminated to allow miners to propagate large blocks very quickly to active network nodes, and would also significantly reduce miner need for peak bandwidth. Currently most miners use a network<ref name="block_relay_net">[http://bitcoinrelaynetwork.org/ Matt Corallo's block relay network]</ref> that is about 25x more efficient than stock Bitcoin Core<ref>[https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2#i-know-that-you-know IBLT design document], Gavin Andresen, 11 August 2014</ref> and almost equally as effective as O(1) block propagation for current block sizes.<br />
<br />
<br />
==== O(n<sup>2</sup>) network total validation resource requirements with decentralization level held constant ====<br />
<br />
[[File:On2_scaling_illustrated.png|thumb|right|visualization of O(n<sup>2</sup>) scaling]]<br />
<br />
While the validation effort required per full node simply grows in O(n), the combined validation effort of all nodes grows by O(n<sup>2</sup>) with decentralization being held constant. For a single node, it takes twice as many resources to process the transactions of twice as many users, while for all nodes it takes a combined four times as many resources to process the transactions of twice as many users assuming the number of full nodes increases in proportion to the number of users.<br />
<br />
Each on-chain Bitcoin transaction needs to be processed by each full node. If we assume that a certain percentage of users run full nodes (''n'') and that each user creates a certain number of transactions on average (''n'' again), then the network’s total resource requirements are <code>n<sup>2</sup> = n * n</code>. In short, this means that the aggregate cost of keeping all transactions on-chain quadruples each time the number of users doubles.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009199.html Total system cost], Dr. Adam Back, 28 June 2015</ref> For example,<br />
<br />
* Imagine a network starts with 100 users and 2 total nodes (a 2% ratio).<br />
<br />
* The network doubles in users to 200. The number of nodes also doubles to 4 (maintaining a 2% ratio of decentralized low-trust security). However, double the number of users means double the number of transactions, and each node needs to process ''every'' transaction---so each node now does double work with its bandwidth and its CPU. With double the number of nodes and double the amount of work per node, total work increases by four times.<br />
<br />
* The network doubles again: 400 users, 8 nodes (still 2% of total), and 4 times the original workload per node for a total of 16 times as much aggregate work as the original.<br />
<br />
* Another doubling: 800 users, 16 nodes (still 2%), and 8 times the original workload per node for a total of 64 times aggregate work as the original.<br />
<br />
* Another doubling: 1,600 users—sixteen times the original---with 32 nodes (still 2%), and 16 times the original workload per node. The aggregate total work done by nodes is 256 times higher than it was originally.<br />
<br />
===== Criticisms =====<br />
<br />
Emphasis on the total validation resource requirements is suggested by some individuals to be misleading, as they claim it obfuscates the growth of the supporting base of full nodes that the total validation resource effort is split amongst. The validation resource effort made by each individual full node increases at O(n), and critics say this is the only pertinent fact with respect to scaling. Some critics also point out that the O(n<sup>2</sup>) network total validation resource requirements claim is assuming decentralization must be held constant as the network scales, and that this is not a founding principle of Bitcoin.<br />
<br />
=== What’s the difference between on-chain and off-chain transactions? ===<br />
<br />
On-chain Bitcoin transactions are those that appear in the Bitcoin block chain. Off-chain transactions are those that transfer ownership of bitcoins without putting a transaction on the block chain.<br />
<br />
Common and proposed off-chain transactions include:<br />
<br />
* '''Exchange transactions:''' when you buy or sell bitcoins, the exchange tracks ownership in a database without putting data in the block chain. Only when you deposit or withdraw bitcoins does the transaction appear on the block chain.<br />
* '''Web wallet internal payments:''' many web wallets allow users of the service to pay other users of the same service using off-chain payments. For example, when one Coinbase user pays another Coinbase user.<br />
* '''Tipping services:''' most tipping services today, such as ChangeTip, use off-chain transactions for everything except deposits and withdrawals.<ref>[https://www.changetip.com/fees ChangeTip fees], retrieved 3 July 2015</ref><br />
* '''Payment channels:''' channels are started using one on-chain transaction and ended using a second on-chain transaction.<ref>[https://bitcoin.org/en/developer-guide#micropayment-channel Micropayment channels], Bitcoin.org Developer Guide</ref> In between can be an essentially unlimited number of off-chain transactions as small as a single satoshi (1/100,000,000th of a bitcoin). Payment channels include those that [https://bitcoinj.github.io/working-with-micropayments exist today] as well as proposed hub-and-spoke channels and the more advanced [http://lightning.network/ Lightning network].<br />
<br />
Approximately 90% to 99% of all bitcoin-denominated payments today are made off-chain.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008844.html Pure off-chain is a weak form of layer 2], Dr. Adam Back, 19 June 2015</ref><br />
<br />
=== What is a fee market? ===<br />
<br />
When you create a Bitcoin transaction, you have the option to pay a [[transaction fee]]. If your software is flexible, you can pay anything from zero fees (a free transaction) to 100% of the value of the transaction (spend-to-fees). This fee is comparable to a tip. The higher it is, the bigger the incentive of the miners to incorporate your transaction into the next block.<br />
<br />
When miners assemble a block, they are free to include whatever transactions they wish. They usually include as many as possible up to the maximum block size and then prioritize the transactions that pay the most fees per kilobyte of data.<ref name="fee_pri">[https://bitcointalk.org/index.php?topic=95837.0 Fee prioritization patch], Gavin Andresen, 26 July 2012</ref> This confirms higher-fee transactions before lower-fee transactions. If blocks become full on a regular basis, users who pay a fee that's too small will have to wait a longer and longer time for their transactions to confirm. At this point, a demand-driven fee market may arise where transactions that pay higher fees get confirmed significantly faster than transactions that pay low fees.<ref name="todd_coinwallet">[https://gist.github.com/petertodd/8e87c782bdf342ef18fb Comments on the CoinWallet.eu tx-flood stress-test], Peter Todd, 22 June 2015</ref><ref name="garzik_bip" /><br />
<br />
In a competitive market, prices are driven by supply and demand and the emerging equilibrium price asymptotically approaches marginal costs over time. However, the current version of Bitcoin limits the supply to 1 MB per block, only allowing demand to adjust. To establish a free market, one would need to come up with a mechanism that allows the number of included transactions per block to adjust dynamically as well. The design of such a mechanism, however, is not trivial. Simply allowing individual miners to include as many transactions as they want is problematic due to the externalities<ref name="exernality">[https://en.wikipedia.org/wiki/Externality Definition of externality], Wikipedia, 26 January 2016</ref> of including additional blocks and explained further in section [[#Should miners be allowed to decide the block size?|'should miners be allowed to decide the block size?']] .<br />
<br />
=== What is the most efficient way to scale Bitcoin? ===<br />
<br />
Remove its decentralization properties, specifically decentralized mining and decentralized full nodes. Mining wastes enormous amounts of electricity to provide a decentralized ledger and full nodes waste an enormous amount of bandwidth and CPU time keeping miners honest.<br />
<br />
If users instead decided to hand authority over to someone they trusted, mining and keeping miners honest wouldn’t be needed. This is how Visa, MasterCard, PayPal, and the rest of the centralized payment systems works—users trust them, and they have no special difficulty scaling to [[scalability|millions of transactions an hour]]. It’s very efficient; it isn’t decentralized.<br />
<br />
=== What is a hard fork, and how does it differ from other types of forks? ===<br />
<br />
The word fork is badly overloaded in Bitcoin development.<br />
<br />
* '''[[hardfork|Hard fork]]:''' a change to the system which is not backwards compatible. Everyone needs to upgrade or things can go wrong.<br />
* '''[[softfork|Soft fork]]:''' a change to the system which is backwards compatible as long as a majority of miners enforce it. Full nodes that don’t upgrade have their security reduced.<br />
* '''Chain fork:''' when there are two are more blocks at the same height on a block chain. This typically happens a few times a week by accident, but it can also indicate more severe problems.<br />
* '''[https://en.wikipedia.org/wiki/Fork_%28software_development%29 Software fork]:''' using the code from an open source project to create a different project.<br />
* '''[https://help.github.com/articles/fork-a-repo/ Git/GitHub fork]:''' a way for developers to write and test new features before contributing them to a project.<br />
<br />
(There are other types of software-related forks, but they don’t tend to cause as much confusion.)<br />
<br />
=== What are the block size soft limits? ===<br />
<br />
Bitcoin Core has historically come pre-configured to limit blocks it mines to certain sizes.<ref name="fee_pri" /> These “limits” aren’t restrictions placed on miners by other miners or nodes, but rather configuration options that help miners produce reasonably-sized blocks.<br />
<br />
Miners can change their soft limit size (up to 1 MB) using <code>-blockmaxsize=&lt;size&gt;</code><br />
<br />
Default soft limits at various times:<br />
<br />
* '''July 2012:''' <code>-blockmaxsize</code> option created and set to default 250 KB soft limit<ref>[https://github.com/bitcoin/bitcoin/commit/c555400ca134991e39d5e3a565fcd2215abe56f6 Bitcoin Core commit c555400], Gavin Andresen, 12 July 2012</ref><br />
* '''November 2013:''' Raised to 750KB<ref>[https://github.com/bitcoin/bitcoin/commit/ad898b40aaf06c1cc7ac12e953805720fc9217c0 Bitcoin Core commit ad898b40], Gavin Andresen, 27 November 2013</ref><br />
* '''June 2015:''' Raise to 1 MB suggested<ref>[https://github.com/bitcoin/bitcoin/pull/6231 Bitcoin Core pull #6231], Chris Wheeler, 4 June 2015</ref><br />
<br />
== General Block Size Increase Theory ==<br />
<br />
Questions about increasing the block size in general, not related to any<br />
specific proposal.<br />
<br />
==== Why are some people in favor of keeping the block size at 1 MB forever? ====<br />
<br />
It is commonly claimed<ref name="garzik_bip" /><ref>[https://epicenterbitcoin.com/podcast/082/ Epicenter Bitcoin podcast #82], Mike Hearn (interviewed), 8 June 2015</ref> that there are people opposed to ever raising the maximum block size limit, but no Bitcoin developers have suggested keeping the maximum block size at one megabyte forever.<ref name="maxwell_not_proposing" /><br />
<br />
All developers support raising the maximum size at some point<ref>[https://www.reddit.com/r/Bitcoin/comments/39kqzs/how_about_a_softfork_optin_blocksize_increase/cs5hj8l Nothing magic about 1MB], Dr. Adam Back, 13 June 2015</ref><ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008328.html Regarding size-independent new block propagation], Pieter Wuille, 28 May 2015</ref>—they just disagree about whether now is the correct time.<br />
<br />
==== Should miners be allowed to decide the block size? ====<br />
<br />
A block may include as little as a single transaction, so miners can always restrict block size. Letting miners choose the maximum block size is more problematic for several reasons:<br />
<br />
# '''Miners profit, others pay the cost:''' bigger blocks earn miners more fees, but miners don’t need to store those blocks for more than a few days.<ref>[https://github.com/bitcoin/bitcoin/pull/5863 Bitcoin Core pull #5863 adding pruning functionality], Suhas Daftuar et al., 6 March 2015</ref> Other users who want full validation security, or who provide services to lightweight wallets, pay the costs of downloading and storing those larger blocks.<br />
# '''Bigger miners can afford more bandwidth:''' each miner needs to download every transaction that will be included in block,<ref name="maxwell_correcting_assumptions" /> which means that they all need to pay for high-speed connections. However, a miner with 8.3% of total hash rate can take that cost out of the about 300 BTC they make a day, while a miner with only 0.7% of total hash rate has to take that cost out of only 25 BTC a day. This means bigger miners may logically choose to make bigger blocks even though it may further centralize mining.<br />
# '''Centralized hardware production:''' only a few companies in the world produce efficient mining equipment, and many of them have chosen to stop selling to the public.<ref>[http://blogs.wsj.com/venturecapital/2014/09/05/for-kncminer-time-to-forget-selling-bitcoin-machines-to-at-home-miners/ KnCMiner to stop selling to home miners], Wall Street Journal, Yuliya Chernova, 5 September 2014</ref> This prevents ordinary Bitcoin users from participating in the process even if they were willing to pay for mining equipment.<br />
# '''Voting by hash rate favors larger miners:''' voting based on hash rate allows the current hash rate majority (or super-majority) to enforce conditions on the minority. This is similar to a lobby of large businesses being able to get laws passed that may hurt smaller businesses.<ref>[https://www.reddit.com/r/Bitcoin/comments/39kzyt/draft_bip_100_soft_fork_block_size_increase/cs5gvak Miners choosing the block size limit is ill-advised], Meni Rosenfeld, 13 June 2015</ref><br />
# '''Miners may not care about users:''' this was demonstrated during the [[July 2015 Forks]] where even after miners lost over $50,000 USD in income from mining invalid chains, and even after they were told that long forks harm users, they continued to mine improperly.<ref>[https://bitcointalk.org/index.php?topic=700411.msg11790734#msg11790734 Intention to continue SPV mining], Wang Chun, 4 July 2015</ref><br />
<br />
However, there are also possible justifications for letting miners choose the block size:<br />
<br />
# '''Authenticated participants:''' miners are active participants in Bitcoin, and they can prove it by adding data to the blocks they create.<ref>[https://bitcoin.org/en/developer-reference#term-coinbase-field Coinbase field], Bitcoin.org Developer Reference</ref> It is much harder to prove people on Reddit, BitcoinTalk, and elsewhere are real people with an active stake in Bitcoin.<br />
# '''Bigger blocks may cost miners:''' small miners and poorly-connected miners are at a disadvantage if larger blocks are produced<ref name="wuille_centralization" />, and even large and well-connected miners may find that large blocks reduce their profit percentage if the cost of bandwidth rises too high or their stale rate increases.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008355.html F2Pool block size concerns], Chun Wang, 29 May 2015</ref><br />
<br />
==== How could a block size increase affect user security? ====<br />
<br />
Bitcoin’s security is highly dependent on the number of active users who protect their bitcoins with a full node like Bitcoin Core. The more active users of full nodes, the harder it is for miners to trick users into accepting fake bitcoins or other frauds.<ref>[https://medium.com/@lopp/bitcoin-nodes-how-many-is-enough-9b8e8f6fd2cf Bitcoin nodes: how many is enough?], Jameson Lopp, 7 June 2015</ref><br />
<br />
Full nodes need to download and verify every block, and most nodes also store blocks plus relay transactions, full blocks, and filtered blocks to other users on the network. The bigger blocks become, the more difficult it becomes to do all this, so it is expected that bigger blocks will both reduce the number of users who currently run full nodes and suppress the number of users who decide to start running a full node later.<ref>[https://www.reddit.com/r/Bitcoin/comments/3bae2d/amir_taaki_on_raising_the_block_size_a_lot_of/cslcgmw Block size increases-only will create problems], Dr. Adam Back, 28 June 2015</ref><br />
<br />
In addition, full blocks may increase mining centralization<ref name="wuille_centralization" /> at a time when mining is already so centralized that it makes it easy to reverse transactions which have been confirmed multiple times.<ref>[http://bitcoin.stackexchange.com/questions/32562/when-to-worry-about-1-confirmation-payments/32564#32564 When to worry about one-confirmation payments], David A. Harding, 17 November 2014</ref><br />
<br />
==== How could larger blocks affect proof-of-work (POW) security? ====<br />
<br />
Proof of work security is dependent on how much money miners spend on mining equipment. However, to effectively mine blocks, miners also need to spend money on bandwidth to receive new transactions and blocks created by other miners; CPUs to validate received transactions and blocks; and bandwidth to upload new blocks. These additional costs don’t directly contribute to POW security.<ref name="maxwell_correcting_assumptions">[https://www.reddit.com/r/Bitcoin/comments/39tgno/letting_miners_vote_on_the_maximum_block_size_is/cs6rek5 Correcting wrong assumptions about mining], Gregory Maxwell, 15 June 2015</ref><br />
<br />
As block sizes increase, the amount of bandwidth and CPU required also increases. If block sizes increase faster than the costs of bandwidth and CPU decrease, miners will have less money for POW security relative to the gross income they earn.<br />
<br />
In addition, larger blocks have a higher risk of becoming stale (orphaned)<ref name="rusty_dsl" />, which directly correlates to lost POW security. For example, if the network average stale rate is 10%, then 10% of POW performed isn't protecting transactions on the block chain.<br />
<br />
Conversely, larger blocks that result in a lower per transaction fee can increase the demand for on-chain transactions, and result in total transaction fees earned by miners increasing despite a lower average transaction fee. This would increase network security by increasing the revenue that supports Proof of Work generation. <br />
<br />
Without an increase in the block size from 1 megabyte, Bitcoin needs $1.50 worth of BTC paid in fees per transaction once block subsidies disappear to maintain current mining revenue and economic expenditure on network security. The required fee per transaction for maintaining current economic expenditure levels once the subsidy disappears decreases as the block size, and with it the maximum on-chain transaction throughput, increases. <br />
<br />
As a result of the sensitivity of demand to price increases, growth in the Bitcoin economy, and thus growth in the fees paid to secure the Bitcoin network, could be stunted if the block size is not allowed to increase sufficiently.<br />
<br />
=== What happens if blocks aren't big enough to include all pending transactions? ===<br />
<br />
This is already the case more often than not<ref>[http://statoshi.info/dashboard/db/transactions?from=1433297061121&to=1435889061123 Statoshi.info mempool queue June to July 2015]</ref>, so we know that miners will simply queue transactions. The transactions eligible for block inclusion that pay the highest fee per kilobyte will be confirmed earlier than transactions that pay comparatively lower fees.<ref name="fee_pri" /><br />
<br />
Basic economic theory tells us that increases in price reduce economic demand, ceteris paribus. Assuming that larger blocks would not cause a loss of demand for on-chain transaction processing due to a perceived loss of the network's decentralization and censorship resistance, blocks that are too small to include all pending transactions will result in demand for on-chain transaction processing being less than it would be if blocks were large enough include all pending transactions.<br />
<br />
What happens from there is debated:<br />
<br />
* BitcoinJ lead developer Mike Hearn believes there would be “crashing nodes, a swelling transaction backlog, a sudden spike in double spending, [and] skyrocketing fees.”<ref>[https://medium.com/@octskyward/crash-landing-f5cc19908e32 Crash Landing], Mike Hearn, 7 May 2015</ref><br />
* Bitcoin Foundation chief scientist Gavin Andresen believes that the “average transaction fee paid will rise, people or applications unwilling or unable to pay the rising fees will stop submitting transactions, [and] people and businesses will shelve plans to use Bitcoin, stunting growth and adoption.” <ref>[https://github.com/bitcoin/bitcoin/pull/6341 Bitcoin Core pull #6341], Gavin Andresen, 26 June 2015</ref><br />
* Bitcoin Core developer Pieter Wuille replies to Andresen’s comment above: “Is it fair to summarize this as ‘Some use cases won’t fit any more, people will decide to no longer use the blockchain for these purposes, and the fees will adapt.’? I think that is already happening […] I don’t think we should be afraid of this change or try to stop it.” <ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009098.html The need for larger blocks], Pieter Wuille, 26 June 2015</ref><br />
* Bitcoin Core developer Jeff Garzik writes, "as blocks get full and the bidding war ensues, the bitcoin user experience rapidly degrades to poor. In part due to bitcoin wallet software’s relative immaturity, and in part due to bitcoin’s settlement based design, the end user experience of their transaction competing for block size results in erratic, and unpredictably extended validation times."<ref name="garzik_bip" /><br />
<br />
== Specific Scaling Proposals ==<br />
<br />
=== Andresen-Hearn Block Size Increase Proposals ===<br />
<br />
Questions about the series of related proposals by Gavin Andresen and Mike Hearn to use a hard fork to raise the maximum block size, thereby allowing miners to include more on-chain transactions. As of July 2015, the current focus is [https://github.com/bitcoin/bips/pull/163 BIP101].<br />
<br />
==== What is the major advantage of this proposal? ====<br />
<br />
''Bitcoin can support many more users.'' Assuming earliest possible adoption, 250 bytes per on-chain transaction, 144 blocks per day, and 2 transaction a day per user, Bitcoin can support about,<br />
<br />
* 288,000 users in 2015<br />
* 2,304,000 users in 2016 (800% increase)<br />
* 4,608,000 in 2018 (1,600%)<br />
* 9,216,000 in 2020 (3,200%)<br />
* 18,432,000 in 2022 (6,400%)<br />
* 36,864,000 in 2024 (12,800%)<br />
* 73,728,000 in 2026 (25,600%)<br />
* 147,456,000 in 2028 (51,200%)<br />
* 294,912,000 in 2030 (102,400%)<br />
* 589,824,000 in 2032 (204,800%)<br />
* 1,179,648,000 in 2034 (409,600%<br />
* 2,359,296,000 in 2036 (819,200%)<br />
<br />
==== What is the major disadvantage of this proposal? ====<br />
<br />
''The total cost of remaining decentralized will be high.'' Assuming earliest possible adoption and that the ratio of total users to full node operators remains the same as today, the total estimated amount of work necessary to maintain the decentralized system under the [[#O.28n2.29_network_total_validation_resource_requirements|O(<sup>2</sup>) scaling model]] will be,<br />
<br />
* 100% of today’s work in 2015<br />
* 6,400% in 2016<br />
* 25,600% in 2018<br />
* 102,400% in 2020<br />
* 409,600% in 2022<br />
* 1,638,400% in 2024<br />
* 6,553,600% in 2026<br />
* 26,214,400% in 2028<br />
* 104,857,600% in 2030<br />
* 419,430,400% in 2032<br />
* 1,677,721,600% in 2034<br />
* 6,710,886,400% in 2036<br />
<br />
For example, if the total amount spent on running full nodes today (not counting mining) is $100 thousand per year, the estimated cost for the same level of decentralization in 2036 will be $6.7 trillion per year if validation costs stay the same. (They'll certainly go down, but algorithmic and hardware improvements probably won't eliminate an approximate 6,710,886,400% cost increase.)<br />
<br />
==== What are the dangers of the proposed hard fork? ====<br />
<br />
Under the current proposal, 75% of miners must indicate that they agree to accept blocks up to 8 MB in size.<ref name="bip101">[https://github.com/bitcoin/bips/pull/163 BIP101], Gavin Andresen, 24 June 2016</ref> After the change goes into effect, if any miner creates a block larger than 1 MB, all nodes which have not upgraded yet will reject the block.<ref>[https://bitcoin.org/en/developer-guide#consensus-rule-changes Consensus rule changes], Bitcoin.org Developer Guide</ref><br />
<br />
If all full nodes have upgraded, or very close to all nodes, there should be no practical effect. If a significant number of full nodes have not upgraded, they will continue using a different block chain than the upgraded users, with the following consequences:<br />
<br />
* Bitcoins received from before the fork can be spent twice, once on both sides of the fork. This creates a high double spend risk.<br />
* Bitcoins received after the fork are only guaranteed to be spendable on the side of the fork they were received on. This means some users will have to lose money to restore Bitcoin to a single chain.<br />
<br />
Users of hosted wallets (Coinbase, BlockChain.info, etc.) will use whatever block chain their host chooses. Users of lightweight P2P SPV wallets will use the [[Thin Client Security|longest chain they know of]], which may not be the actual longest chain if they only connect to nodes on the shorter chain. Users of non-P2P SPV wallets, like Electrum, will use whatever chain is used by the server they connect to.<br />
<br />
If a bad hard fork like this happens, it will likely cause large-scale confusion and make Bitcoin very hard to use until the situation is resolved.<br />
<br />
==== What is the deployment schedule for BIP 101? ====<br />
<br />
* The patch needs to be accepted into Bitcoin Core, Bitcoin XT, or both.<br />
* If accepted into Bitcoin Core, miners using that software will need to upgrade (this probably requires a new released version of Bitcoin Core). If accepted only into Bitcoin XT, miners will need to switch to using XT.<br />
* After 75% of miners have upgraded, 8MB blocks will become allowed at the the latest of (1) 11 January 2016 or (2) two weeks after the 75% upgrade threshold.<ref name="bip101" /><br />
* After the effective date has passed, any miner may create a block larger than 8MB. When a miner does this, upgraded full nodes will accept that block and non-upgraded full nodes will reject it, forking the network.<ref name="bip101" /> See [[#What_are_the_dangers_of_the_proposed_hard_fork.3F|hard fork dangers]] for what his might mean.<br />
<br />
==== Will miners go straight from 1 MB blocks to 8 MB blocks? ====<br />
<br />
That would be highly unlikely. Uploading an 8 MB block currently takes significantly more time than uploading a 1 MB block<ref name="rusty_dsl">[http://rusty.ozlabs.org/?p=509 Mining on a home DSL connection test results], Rusty Russell, 19 June 2015</ref>, even with the roughly 25x reduction in size available from use of Matt Corallo’s block relay network.<ref name="block_relay_net" /><br />
<br />
The longer it takes to upload a block, the higher the risk it will become a stale block—meaning the miner who created it will not receive the block subsidy or transaction fees (currently about 25 BTC per block).<br />
<br />
However, if technology like Invertible Bloom Lookup Tables (IBLTs) is deployed and found to work as expected<ref name="iblt">[https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2 O(1) block propagation], Gavin Andresen, 8 August 2014</ref>, or if mining [[#What_is_the_most_efficient_way_to_scale_Bitcoin.3F|centralizes further]], adding additional transactions may not have a significant enough cost to discourage miners from creating full blocks. In that case, blocks will be filled as soon as there are enough people wanting to make transactions paying the default relay fee<ref>[https://github.com/bitcoin/bitcoin/pull/3305 Bitcoin Core pull #3305 dropping default fees], Mike Hearn, 22 November 2013</ref> of 0.00001000 BTC/kilobyte.<br />
<br />
==== What tests have been performed related to this proposal? ====<br />
<br />
* '''20MB block processing''' (Gavin Andresen) “if we increased the maximum block size to 20 megabytes tomorrow, and every single miner decided to start creating 20MB blocks and there was a sudden increase in the number of transactions on the network to fill up those blocks… the 0.10.0 version of [Bitcoin Core] would run just fine.”<ref>[http://gavintech.blogspot.com/2015/01/twenty-megabytes-testing-results.html Twenty megabyte block testing], Gavin Andresen, 20 January 2015</ref> (ellipses in original)<br />
* '''Mining &amp; relay simulation''' (Gavin Andresen) “if blocks take 20 seconds to propagate, a network with a miner that has 30% of the hashing power will get 30.3% of the blocks.”<ref>[http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners Are bigger blocks better for bigger miners?], Gavin Andresen, 22 May 2015</ref><br />
* '''Mining on a home DSL connection''' (Rusty Russell) “Using the rough formula of 1-exp(-t/600), I would expect orphan rates of 10.5% generating 1MB blocks, and 56.6% with 8MB blocks; that’s a huge cut in expected profits.”<ref name="rusty_dsl" /><br />
* '''Mining centralization pressure''' (Pieter Wuille) “[This] does very clearly show the effects of larger blocks on centralization pressure of the system.”<ref name="wuille_centralization">[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008581.html Mining centralization pressure from non-uniform propagation speed], Pieter Wuille, 12 June 2015</ref><br />
<br />
<br />
=== Garzik Miner Block Size Voting Proposal (AKA BIP100) ===<br />
<br />
''Note, BIP 100 is the marketing name for this proposal. No BIP number<br />
has yet been publicly requested, and the number assigned is unlikely to<br />
be 100.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-May/005756.html<br />
Prenumbered BIP naming], Gregory Maxwell, 12 May 2014</ref>''<br />
<br />
Questions related to Jeff Garzik's proposal<ref name="garzik_bip">[http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf Draft BIP: decentralized economic policy], Jeff Garzik, 12 June 2015 (revised 15 June 2015)</ref> to allow miners to vote on raising and lowering the maximum block size.<br />
<br />
==== What does this proposal do? ====<br />
<br />
# It creates a one-time hard fork that does not automatically change the maximum block size.<br />
<br />
# It allows miners to vote to increase or decrease the maximum block size within the range of 1MB to 32MB. These changes are neither hard forks nor soft forks, but simply rules that all nodes should know about after the initial hard fork.<br />
<br />
==== Does it reduce the risk of a hard fork? ====<br />
<br />
Hard forks are most dangerous when they're done without strong<br />
consensus.<ref name="garzik_bip" /><ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008779.html Consensus changes are not about making a change to the software],<br />
Pieter Wuille, 18 June 2015</ref><br />
<br />
If Garzik's proposal gains strong consensus, it will be as safe as possible<br />
for a hard fork and it will allow increasing the block size up to 32 MB<br />
without any additional risk of a fork.<br />
<br />
==== Why is it limited to 32 megabytes? ====<br />
<br />
According to the draft BIP, "the 32 MB hard fork is largely coincidental -- a whole network upgrade at 32 MB was likely needed anyway."<br />
<br />
=== Lightning Network ===<br />
<br />
Questions related to using the proposed [http://lightning.network/ Lightning network] as a way to scale the number of users Bitcoin can support.<br />
<br />
==== How does transaction security differ from that of Bitcoin? ====<br />
<br />
Transactions on the proposed Lightning network use Bitcoin transactions exclusively to transfer bitcoins<ref name="russell_lightning1">[http://rusty.ozlabs.org/?p=450 Lightning Networks: Part I], Rusty Russell, 30 March 2015</ref>, and so the same security as regular Bitcoin transactions is provided when both a Lightning hub and client are cooperating.<br />
<br />
When a Lightning hub or client refuses to cooperate with the other (maybe because they accidentally went offline), the other party can still receive their full 100% bitcoin balance by closing the payment channel—but they must first wait for a defined amount of time mutually chosen by both the hub and client.<ref>[http://rusty.ozlabs.org/?p=462 Lightning Networks: Part II], Rusty Russell, 1 April 2015</ref><br />
<br />
If one party waits too long to close the payment channel, the other party may be able to steal bitcoins. However, it is possible to delegate the task of closing the channel in an emergency to an unlimited number of hubs around the Internet, so closing the channel on time should be easy.<ref name="russell_lightning4">[http://rusty.ozlabs.org/?p=477 Lightning Networks: Part IV], Rusty Russell, 8 April 2015</ref><br />
<br />
In summary, provided that payment channels are closed on time, the worst that can happen to users is that they may have to wait a few weeks for a channel to fully close before spending the bitcoins they received from it. Their security is otherwise the same as with regular Bitcoin.<br />
<br />
For Lightning hubs, security is slightly worse in the sense that they need to keep a potentially-large amount of funds in a hot wallet<ref name="lightning_paper">[http://lightning.network/lightning-network-paper-DRAFT-0.5.pdf Lightning Network (Draft 0.5)], Section 6.3: Coin Theft via Hacking, Joseph Poon and Thaddeus Dryja</ref>, so they can’t take advantage of the anti-hacking protection offered by cold wallets. Otherwise, Lightning hubs have the same security as clients.<br />
<br />
==== When will Lightning be ready for use? ====<br />
<br />
Lightning requires a basic test implementation (work underway<ref>[https://lists.blockstream.com/pipermail/lightning-dev/2015-June/000018.html Lightning first steps], Rusty Russell, 13 June 2015</ref>), several soft-fork changes to the Bitcoin protocol (work underway<ref>[https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65: CheckLockTimeVerify], Peter Todd, 1 October 2014</ref><ref>[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68: Consensus-enforced transaction replacement], Mark Friedenbach, 28 May 2015</ref>, and wallets need to be updated to support the Lightning network protocol.<ref name="russell_lightning4" /><br />
<br />
Dr. Adam Back has said, "I expect we can get something running inside a year."<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009242.html Reply to Andresen regarding Lightning], Dr. Adam Back, 28 June 2015</ref><br />
<br />
==== Doesn’t Lightning require bigger blocks anyway? ====<br />
<br />
Lightning is block-size neutral. It requires one on-chain transaction to open a channel between a hub and a client, and one on-chain transaction to close a channel.<ref name="russell_lightning1" /> In between it can support an unlimited number of transactions between anyone on the Lightning network.<ref name="lightning_paper" /><br />
<br />
Using the numbers from the Lightning presentation<ref name="lightning_slides">[http://lightning.network/lightning-network.pdf Lightning presentation], Joseph Poon, 23 February 2015</ref>, if people open and close a plausible two channels a year, Lightning can support about 52 million users with the current one-megabyte limit—and each user can make an unlimited number of transactions. Currently, assuming people make an average of only two Bitcoin transactions a day, basic Bitcoin can support only 288,000 users.<br />
<br />
Under these assumptions, Lightning is 180 times (17,900%) more efficient than basic Bitcoin.<br />
<br />
Presumably, if around 30 million people are using Bitcoin via Lightning so that capacity is called into question, it will not be difficult to find consensus to double the block size to two megabytes and bring user capacity up to 105 million. The same goes for later increases to 200 million (4MB), 400 million (8MB), 800 million (16MB), 1.6 billion (32 MB), 3.2 billion (64MB), and all 7 billion living humans (133MB). In each case, all Lightning network participants get unlimited transactions to the other participants.<br />
<br />
For basic Bitcoin to scale to just 2 transactions a day for 7 billion people would require 24-gigabyte blocks.<ref name="lightning_slides" /><br />
<br />
=== Sidechains ===<br />
<br />
==== Real quick, what are sidechains? ====<br />
<br />
Block chains that are separate from Bitcoin’s block chain, but which allow you to receive and spend bitcoins using a two-way peg (2WP).<ref name="sidechains_paper">[https://www.blockstream.com/sidechains.pdf Sidechains paper], Adam Back et al., 22 October 2014</ref> (Although a sidechain can never be more secure than the Bitcoin block chain.<ref>[https://www.reddit.com/r/Bitcoin/comments/39r85g/sidechain_hate/cs5spbg Security limitations of pegged chains], Gregory Maxwell, 14 June 2015</ref>)<br />
<br />
==== Are sidechains a scaling option? ====<br />
<br />
No. Sidechains have the same fundamental scaling problems as Bitcoin does. Moving some transactions to sidechains simply moves some problems elsewhere on the network—the total difficulty of the problem remains the same.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008617.html Sidechains not a direct means for solving any of the scaling problems Bitcoin has], Pieter Wuille, 13 June 2015</ref><br />
<br />
==== But couldn’t I create a sidechain that had 100 GB blocks? ====<br />
<br />
Certainly, sidechain code is open source<ref>[https://github.com/ElementsProject/elements Elements Project]</ref>—so you can create your own sidechain. But you’d still have the difficulty of finding people who are willing to validate 100 GB blocks with their own full nodes.<br />
<br />
==== Do sidechains require a hard fork? ====<br />
<br />
No. Federated sidechains, such as have already been implemented<ref>[https://github.com/ElementsProject/elements/tree/alpha Elements Alpha]</ref>, don’t require any changes to the Bitcoin consensus rules. Merged-mined sidechains, which have not been implemented yet, do require a backwards-compatible soft fork in order to transfer funds between Bitcoin and the sidechain.<ref name="sidechains_paper" /><br />
<br />
== References ==<br />
<references /></div>Amincdhttps://en.bitcoin.it/w/index.php?title=Scalability_FAQ&diff=60396Scalability FAQ2016-02-14T18:35:51Z<p>Amincd: /* O(n2) network total validation resource requirements */ made it clearer, and added criticisms</p>
<hr />
<div>Answers to commonly-asked questions and concerns about scaling Bitcoin, including “level 1” solutions such as increasing the block size and “level 2” solutions such as the proposed Lightning network.<br />
<br />
== Background ==<br />
<br />
Questions about how Bitcoin currently works (related to scaling) as well as questions about the technical terminology related to the scaling discussion.<br />
<br />
=== What is the short history of the block size limit? ===<br />
<br />
''Note: the software now called Bitcoin Core was previously simply called “Bitcoin”.<ref>[https://bitcoin.org/en/release/v0.9.0#rebranding-to-bitcoin-core Bitcoin Core 0.9.0 release notes], Bitcoin.org, 19 March 2014</ref> To avoid confusion with the Bitcoin system, we’ll use the Bitcoin Core name.''<br />
<br />
Bitcoin Core was initially released without an explicit block size limit. However, the code did limit network messages to a maximum of 32 MiB, setting an effective upper bound on block size.<ref>[https://bitcointalk.org/index.php?topic=68121 Earliest known Bitcoin code], <code>src/main.h:17</code></ref><br />
<br />
Around 15 July 2010, Satoshi Nakamoto changed Bitcoin Core’s mining code so that it wouldn’t create any blocks larger than 990,000 bytes.<ref>[https://github.com/bitcoin/bitcoin/commit/a30b56ebe76ffff9f9cc8a6667186179413c6349 Bitcoin Core commit a30b56e], Satoshi Nakamoto, 15 July 2010</ref><br />
<br />
Two months later on 7 September 2010, Nakamoto changed Bitcoin Core’s consensus rules to reject blocks larger than 1,000,000 bytes (1 megabyte) if their block height was higher than 79,400.<ref>[https://github.com/bitcoin/bitcoin/commit/8c9479c6bbbc38b897dc97de9d04e4d5a5a36730 Bitcoin Core commit 8c9479c], Satoshi Nakamoto, 7 September 2010</ref> (Block 79,400 was later produced on 12 September 2010.<ref>[https://www.biteasy.com/blockchain/blocks/000000000021d821ec06be7173f413690bc5c4bc648dfa70b3b6763236f055b7 Block height 79400], dated 12 September 2010</ref>)<br />
<br />
Neither the July nor the September commit message explains the reason for the limit, although the careful attempt to prevent a fork may indicate Nakamoto didn’t consider it an emergency.<br />
<br />
Nakamoto’s subsequent statements supported raising the block size at a later time<ref>[https://bitcointalk.org/index.php?topic=1347.msg15139#msg15139 Increasing the block size when needed], Satoshi Nakamoto, 3 October 2010</ref>, but he never publicly specified a date or set of conditions for the raise.<br />
<br />
Statements by Nakamoto in the summer of 2010 indicate he believed Bitcoin could scale to block sizes far larger 1 megabyte. For example, on 5 August 2010, he wrote that "[W]hatever size micropayments you need will eventually be practical. I think in 5 or 10 years, the bandwidth and storage will seem trivial" and "[microtransactions on the blockchain] can become more practical ... if I implement client-only mode and the number of network nodes consolidates into a smaller number of professional server farms" <ref>[https://bitcointalk.org/index.php?topic=532.msg6306#msg6306 the number of network nodes consolidates into a smaller number of professional server farms]</ref>. <br />
<br />
These statements suggest that the intended purpose of the 1 megabyte limit was not to keep bandwidth and storage requirements for running a Bitcoin node low enough to be practical for personal computers and consumer-grade internet connections, and that the limit would be lifted to accommodate greater demand for transactional capacity.<br />
<br />
=== What is this Transactions Per Second (TPS) limit? ===<br />
<br />
The current block size limit is 1,000,000 bytes (1 megabyte)<ref>[https://github.com/bitcoin/bitcoin/blob/41076aad0cbdfa4c4cf376e345114a5c29086f81/src/consensus/consensus.h#L10 <code>MAX_BLOCK_SIZE</code>], retrieved 2 July 2015</ref>, although a small amount of that space (such as the block header) is not available to store transactions.<ref>[https://bitcoin.org/en/developer-reference#serialized-blocks Block serialization description], Bitcoin.org Developer Reference</ref><br />
<br />
Bitcoin transactions vary in size depending on multiple factors, such as whether they’re spending single-signature inputs or a multiple signature inputs, and how many inputs and outputs they have.<br />
<br />
The simple way to calculate the number of Transactions Per Second (TPS) Bitcoin can handle is to divide the block size limit by the expected average size of transactions, divided by the average number of seconds between blocks (600). For example, if you assume average transactions are 250 bytes,<br />
<br />
<pre>6.6 TPS = 1,000,000 / 250 / 600</pre><br />
<br />
There seems to be general agreement that Bitcoin in 2015 can handle about 3 TPS with the current average size of transactions.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/007986.html Max TPS based on current average transaction size], Mike Hearn, 8 May 2015</ref><ref name="maxwell_not_proposing">[https://www.reddit.com/r/Bitcoin/comments/39yaod/bitcoinorg_position_on_hard_forks/cs7qz5c "No one proposing 3 TPS forever"], Gregory Maxwell, 15 June 2015</ref><br />
<br />
Both old estimates<ref>[[Scalability]], Bitcoin Wiki, retrieved 7 July<br />
2015</ref> and new estimates<ref name="garzik_bip" /> place the<br />
theoretical maximum at 7 TPS with current Bitcoin consensus rules<br />
(including the 1MB block size limit).<br />
<br />
=== What do devs mean by the scaling expressions O(1), O(n), O(n<sup>2</sup>), etc…? ===<br />
<br />
[https://en.wikipedia.org/wiki/Big_O_notation Big O notation] is a shorthand used by computer scientists to describe how well a system scales. Such descriptions are rough approximations meant to help predict potential problems and evaluate potential solutions; they are not usually expected to fully capture all variables.<br />
<br />
* '''O(1)''' means a system has roughly the same properties no matter how big it gets.<br />
* '''O(n)''' means that a system scales linearly: doubling the number of things (users, transactions, etc.) doubles the amount of work.<br />
* '''O(n<sup>2</sup>)''' means that a system scales quadratically : doubling (2x) the number of things quadruples (4x) the amount of work. Often written O(n^2) is places without convenient superscripts.<br />
* Additional examples may be found in the [https://en.wikipedia.org/wiki/Big_O_notation#Orders_of_common_functions Wikipedia article]<br />
<br />
The following subsections show cases where big O notation has been applied to the scaling Bitcoin transaction volume.<br />
<br />
==== O(1) block propagation ====<br />
<br />
Bitcoin Core currently relays unconfirmed transactions and then later relays blocks containing many of the same transactions. This redundant relay can be eliminated to allow miners to propagate large blocks very quickly to active network nodes, and would also significantly reduce miner need for peak bandwidth. Currently most miners use a network<ref name="block_relay_net">[http://bitcoinrelaynetwork.org/ Matt Corallo's block relay network]</ref> that is about 25x more efficient than stock Bitcoin Core<ref>[https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2#i-know-that-you-know IBLT design document], Gavin Andresen, 11 August 2014</ref> and almost equally as effective as O(1) block propagation for current block sizes.<br />
<br />
<br />
==== O(n<sup>2</sup>) network total validation resource requirements with decentralization level held constant ====<br />
<br />
[[File:On2_scaling_illustrated.png|thumb|right|visualization of O(n<sup>2</sup>) scaling]]<br />
<br />
While the validation effort required per full node simply grows in O(n), the combined validation effort of all nodes grows by O(n<sup>2</sup>) with decentralization being held constant. For a single node, it takes twice as many resources to process the transactions of twice as many users, while for all nodes it takes a combined four times as many resources to process the transactions of twice as many users assuming the number of full nodes increases in proportion to the number of users.<br />
<br />
Each on-chain Bitcoin transaction needs to be processed by each full node. If we assume that a certain percentage of users run full nodes (''n'') and that each user creates a certain number of transactions on average (''n'' again), then the network’s total resource requirements are <code>n<sup>2</sup> = n * n</code>. In short, this means that the aggregate cost of keeping all transactions on-chain quadruples each time the number of users doubles.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009199.html Total system cost], Dr. Adam Back, 28 June 2015</ref> For example,<br />
<br />
* Imagine a network starts with 100 users and 2 total nodes (a 2% ratio).<br />
<br />
* The network doubles in users to 200. The number of nodes also doubles to 4 (maintaining a 2% ratio of decentralized low-trust security). However, double the number of users means double the number of transactions, and each node needs to process ''every'' transaction---so each node now does double work with its bandwidth and its CPU. With double the number of nodes and double the amount of work per node, total work increases by four times.<br />
<br />
* The network doubles again: 400 users, 8 nodes (still 2% of total), and 4 times the original workload per node for a total of 16 times as much aggregate work as the original.<br />
<br />
* Another doubling: 800 users, 16 nodes (still 2%), and 8 times the original workload per node for a total of 64 times aggregate work as the original.<br />
<br />
* Another doubling: 1,600 users—sixteen times the original---with 32 nodes (still 2%), and 16 times the original workload per node. The aggregate total work done by nodes is 256 times higher than it was originally.<br />
<br />
===== Criticisms =====<br />
<br />
Emphasis on the total validation resource requirements is suggested by some individuals to be misleading, as they claim it obfuscates the growth of the supporting base of full nodes that the total validation resource effort is split amongst. The validation resource effort made by each individual full node increases at O(n), and critics say this is the only pertinent fact with respect to scaling. Some critics also point out that is also based on an assumption that the O(n<sup>2</sup>) network total validation resource requirements claim is assuming decentralization must be held constant as the network scales, which is not a founding principle of Bitcoin.<br />
<br />
=== What’s the difference between on-chain and off-chain transactions? ===<br />
<br />
On-chain Bitcoin transactions are those that appear in the Bitcoin block chain. Off-chain transactions are those that transfer ownership of bitcoins without putting a transaction on the block chain.<br />
<br />
Common and proposed off-chain transactions include:<br />
<br />
* '''Exchange transactions:''' when you buy or sell bitcoins, the exchange tracks ownership in a database without putting data in the block chain. Only when you deposit or withdraw bitcoins does the transaction appear on the block chain.<br />
* '''Web wallet internal payments:''' many web wallets allow users of the service to pay other users of the same service using off-chain payments. For example, when one Coinbase user pays another Coinbase user.<br />
* '''Tipping services:''' most tipping services today, such as ChangeTip, use off-chain transactions for everything except deposits and withdrawals.<ref>[https://www.changetip.com/fees ChangeTip fees], retrieved 3 July 2015</ref><br />
* '''Payment channels:''' channels are started using one on-chain transaction and ended using a second on-chain transaction.<ref>[https://bitcoin.org/en/developer-guide#micropayment-channel Micropayment channels], Bitcoin.org Developer Guide</ref> In between can be an essentially unlimited number of off-chain transactions as small as a single satoshi (1/100,000,000th of a bitcoin). Payment channels include those that [https://bitcoinj.github.io/working-with-micropayments exist today] as well as proposed hub-and-spoke channels and the more advanced [http://lightning.network/ Lightning network].<br />
<br />
Approximately 90% to 99% of all bitcoin-denominated payments today are made off-chain.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008844.html Pure off-chain is a weak form of layer 2], Dr. Adam Back, 19 June 2015</ref><br />
<br />
=== What is a fee market? ===<br />
<br />
When you create a Bitcoin transaction, you have the option to pay a [[transaction fee]]. If your software is flexible, you can pay anything from zero fees (a free transaction) to 100% of the value of the transaction (spend-to-fees). This fee is comparable to a tip. The higher it is, the bigger the incentive of the miners to incorporate your transaction into the next block.<br />
<br />
When miners assemble a block, they are free to include whatever transactions they wish. They usually include as many as possible up to the maximum block size and then prioritize the transactions that pay the most fees per kilobyte of data.<ref name="fee_pri">[https://bitcointalk.org/index.php?topic=95837.0 Fee prioritization patch], Gavin Andresen, 26 July 2012</ref> This confirms higher-fee transactions before lower-fee transactions. If blocks become full on a regular basis, users who pay a fee that's too small will have to wait a longer and longer time for their transactions to confirm. At this point, a demand-driven fee market may arise where transactions that pay higher fees get confirmed significantly faster than transactions that pay low fees.<ref name="todd_coinwallet">[https://gist.github.com/petertodd/8e87c782bdf342ef18fb Comments on the CoinWallet.eu tx-flood stress-test], Peter Todd, 22 June 2015</ref><ref name="garzik_bip" /><br />
<br />
In a competitive market, prices are driven by supply and demand and the emerging equilibrium price asymptotically approaches marginal costs over time. However, the current version of Bitcoin limits the supply to 1 MB per block, only allowing demand to adjust. To establish a free market, one would need to come up with a mechanism that allows the number of included transactions per block to adjust dynamically as well. The design of such a mechanism, however, is not trivial. Simply allowing individual miners to include as many transactions as they want is problematic due to the externalities<ref name="exernality">[https://en.wikipedia.org/wiki/Externality Definition of externality], Wikipedia, 26 January 2016</ref> of including additional blocks and explained further in section [[#Should miners be allowed to decide the block size?|'should miners be allowed to decide the block size?']] .<br />
<br />
=== What is the most efficient way to scale Bitcoin? ===<br />
<br />
Remove its decentralization properties, specifically decentralized mining and decentralized full nodes. Mining wastes enormous amounts of electricity to provide a decentralized ledger and full nodes waste an enormous amount of bandwidth and CPU time keeping miners honest.<br />
<br />
If users instead decided to hand authority over to someone they trusted, mining and keeping miners honest wouldn’t be needed. This is how Visa, MasterCard, PayPal, and the rest of the centralized payment systems works—users trust them, and they have no special difficulty scaling to [[scalability|millions of transactions an hour]]. It’s very efficient; it isn’t decentralized.<br />
<br />
=== What is a hard fork, and how does it differ from other types of forks? ===<br />
<br />
The word fork is badly overloaded in Bitcoin development.<br />
<br />
* '''[[hardfork|Hard fork]]:''' a change to the system which is not backwards compatible. Everyone needs to upgrade or things can go wrong.<br />
* '''[[softfork|Soft fork]]:''' a change to the system which is backwards compatible as long as a majority of miners enforce it. Full nodes that don’t upgrade have their security reduced.<br />
* '''Chain fork:''' when there are two are more blocks at the same height on a block chain. This typically happens a few times a week by accident, but it can also indicate more severe problems.<br />
* '''[https://en.wikipedia.org/wiki/Fork_%28software_development%29 Software fork]:''' using the code from an open source project to create a different project.<br />
* '''[https://help.github.com/articles/fork-a-repo/ Git/GitHub fork]:''' a way for developers to write and test new features before contributing them to a project.<br />
<br />
(There are other types of software-related forks, but they don’t tend to cause as much confusion.)<br />
<br />
=== What are the block size soft limits? ===<br />
<br />
Bitcoin Core has historically come pre-configured to limit blocks it mines to certain sizes.<ref name="fee_pri" /> These “limits” aren’t restrictions placed on miners by other miners or nodes, but rather configuration options that help miners produce reasonably-sized blocks.<br />
<br />
Miners can change their soft limit size (up to 1 MB) using <code>-blockmaxsize=&lt;size&gt;</code><br />
<br />
Default soft limits at various times:<br />
<br />
* '''July 2012:''' <code>-blockmaxsize</code> option created and set to default 250 KB soft limit<ref>[https://github.com/bitcoin/bitcoin/commit/c555400ca134991e39d5e3a565fcd2215abe56f6 Bitcoin Core commit c555400], Gavin Andresen, 12 July 2012</ref><br />
* '''November 2013:''' Raised to 750KB<ref>[https://github.com/bitcoin/bitcoin/commit/ad898b40aaf06c1cc7ac12e953805720fc9217c0 Bitcoin Core commit ad898b40], Gavin Andresen, 27 November 2013</ref><br />
* '''June 2015:''' Raise to 1 MB suggested<ref>[https://github.com/bitcoin/bitcoin/pull/6231 Bitcoin Core pull #6231], Chris Wheeler, 4 June 2015</ref><br />
<br />
== General Block Size Increase Theory ==<br />
<br />
Questions about increasing the block size in general, not related to any<br />
specific proposal.<br />
<br />
==== Why are some people in favor of keeping the block size at 1 MB forever? ====<br />
<br />
It is commonly claimed<ref name="garzik_bip" /><ref>[https://epicenterbitcoin.com/podcast/082/ Epicenter Bitcoin podcast #82], Mike Hearn (interviewed), 8 June 2015</ref> that there are people opposed to ever raising the maximum block size limit, but no Bitcoin developers have suggested keeping the maximum block size at one megabyte forever.<ref name="maxwell_not_proposing" /><br />
<br />
All developers support raising the maximum size at some point<ref>[https://www.reddit.com/r/Bitcoin/comments/39kqzs/how_about_a_softfork_optin_blocksize_increase/cs5hj8l Nothing magic about 1MB], Dr. Adam Back, 13 June 2015</ref><ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008328.html Regarding size-independent new block propagation], Pieter Wuille, 28 May 2015</ref>—they just disagree about whether now is the correct time.<br />
<br />
==== Should miners be allowed to decide the block size? ====<br />
<br />
A block may include as little as a single transaction, so miners can always restrict block size. Letting miners choose the maximum block size is more problematic for several reasons:<br />
<br />
# '''Miners profit, others pay the cost:''' bigger blocks earn miners more fees, but miners don’t need to store those blocks for more than a few days.<ref>[https://github.com/bitcoin/bitcoin/pull/5863 Bitcoin Core pull #5863 adding pruning functionality], Suhas Daftuar et al., 6 March 2015</ref> Other users who want full validation security, or who provide services to lightweight wallets, pay the costs of downloading and storing those larger blocks.<br />
# '''Bigger miners can afford more bandwidth:''' each miner needs to download every transaction that will be included in block,<ref name="maxwell_correcting_assumptions" /> which means that they all need to pay for high-speed connections. However, a miner with 8.3% of total hash rate can take that cost out of the about 300 BTC they make a day, while a miner with only 0.7% of total hash rate has to take that cost out of only 25 BTC a day. This means bigger miners may logically choose to make bigger blocks even though it may further centralize mining.<br />
# '''Centralized hardware production:''' only a few companies in the world produce efficient mining equipment, and many of them have chosen to stop selling to the public.<ref>[http://blogs.wsj.com/venturecapital/2014/09/05/for-kncminer-time-to-forget-selling-bitcoin-machines-to-at-home-miners/ KnCMiner to stop selling to home miners], Wall Street Journal, Yuliya Chernova, 5 September 2014</ref> This prevents ordinary Bitcoin users from participating in the process even if they were willing to pay for mining equipment.<br />
# '''Voting by hash rate favors larger miners:''' voting based on hash rate allows the current hash rate majority (or super-majority) to enforce conditions on the minority. This is similar to a lobby of large businesses being able to get laws passed that may hurt smaller businesses.<ref>[https://www.reddit.com/r/Bitcoin/comments/39kzyt/draft_bip_100_soft_fork_block_size_increase/cs5gvak Miners choosing the block size limit is ill-advised], Meni Rosenfeld, 13 June 2015</ref><br />
# '''Miners may not care about users:''' this was demonstrated during the [[July 2015 Forks]] where even after miners lost over $50,000 USD in income from mining invalid chains, and even after they were told that long forks harm users, they continued to mine improperly.<ref>[https://bitcointalk.org/index.php?topic=700411.msg11790734#msg11790734 Intention to continue SPV mining], Wang Chun, 4 July 2015</ref><br />
<br />
However, there are also possible justifications for letting miners choose the block size:<br />
<br />
# '''Authenticated participants:''' miners are active participants in Bitcoin, and they can prove it by adding data to the blocks they create.<ref>[https://bitcoin.org/en/developer-reference#term-coinbase-field Coinbase field], Bitcoin.org Developer Reference</ref> It is much harder to prove people on Reddit, BitcoinTalk, and elsewhere are real people with an active stake in Bitcoin.<br />
# '''Bigger blocks may cost miners:''' small miners and poorly-connected miners are at a disadvantage if larger blocks are produced<ref name="wuille_centralization" />, and even large and well-connected miners may find that large blocks reduce their profit percentage if the cost of bandwidth rises too high or their stale rate increases.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008355.html F2Pool block size concerns], Chun Wang, 29 May 2015</ref><br />
<br />
==== How could a block size increase affect user security? ====<br />
<br />
Bitcoin’s security is highly dependent on the number of active users who protect their bitcoins with a full node like Bitcoin Core. The more active users of full nodes, the harder it is for miners to trick users into accepting fake bitcoins or other frauds.<ref>[https://medium.com/@lopp/bitcoin-nodes-how-many-is-enough-9b8e8f6fd2cf Bitcoin nodes: how many is enough?], Jameson Lopp, 7 June 2015</ref><br />
<br />
Full nodes need to download and verify every block, and most nodes also store blocks plus relay transactions, full blocks, and filtered blocks to other users on the network. The bigger blocks become, the more difficult it becomes to do all this, so it is expected that bigger blocks will both reduce the number of users who currently run full nodes and suppress the number of users who decide to start running a full node later.<ref>[https://www.reddit.com/r/Bitcoin/comments/3bae2d/amir_taaki_on_raising_the_block_size_a_lot_of/cslcgmw Block size increases-only will create problems], Dr. Adam Back, 28 June 2015</ref><br />
<br />
In addition, full blocks may increase mining centralization<ref name="wuille_centralization" /> at a time when mining is already so centralized that it makes it easy to reverse transactions which have been confirmed multiple times.<ref>[http://bitcoin.stackexchange.com/questions/32562/when-to-worry-about-1-confirmation-payments/32564#32564 When to worry about one-confirmation payments], David A. Harding, 17 November 2014</ref><br />
<br />
==== How could larger blocks affect proof-of-work (POW) security? ====<br />
<br />
Proof of work security is dependent on how much money miners spend on mining equipment. However, to effectively mine blocks, miners also need to spend money on bandwidth to receive new transactions and blocks created by other miners; CPUs to validate received transactions and blocks; and bandwidth to upload new blocks. These additional costs don’t directly contribute to POW security.<ref name="maxwell_correcting_assumptions">[https://www.reddit.com/r/Bitcoin/comments/39tgno/letting_miners_vote_on_the_maximum_block_size_is/cs6rek5 Correcting wrong assumptions about mining], Gregory Maxwell, 15 June 2015</ref><br />
<br />
As block sizes increase, the amount of bandwidth and CPU required also increases. If block sizes increase faster than the costs of bandwidth and CPU decrease, miners will have less money for POW security relative to the gross income they earn.<br />
<br />
In addition, larger blocks have a higher risk of becoming stale (orphaned)<ref name="rusty_dsl" />, which directly correlates to lost POW security. For example, if the network average stale rate is 10%, then 10% of POW performed isn't protecting transactions on the block chain.<br />
<br />
Conversely, larger blocks that result in a lower per transaction fee can increase the demand for on-chain transactions, and result in total transaction fees earned by miners increasing despite a lower average transaction fee. This would increase network security by increasing the revenue that supports Proof of Work generation. <br />
<br />
Without an increase in the block size from 1 megabyte, Bitcoin needs $1.50 worth of BTC paid in fees per transaction once block subsidies disappear to maintain current mining revenue and economic expenditure on network security. The required fee per transaction for maintaining current economic expenditure levels once the subsidy disappears decreases as the block size, and with it the maximum on-chain transaction throughput, increases. <br />
<br />
As a result of the sensitivity of demand to price increases, growth in the Bitcoin economy, and thus growth in the fees paid to secure the Bitcoin network, could be stunted if the block size is not allowed to increase sufficiently.<br />
<br />
=== What happens if blocks aren't big enough to include all pending transactions? ===<br />
<br />
This is already the case more often than not<ref>[http://statoshi.info/dashboard/db/transactions?from=1433297061121&to=1435889061123 Statoshi.info mempool queue June to July 2015]</ref>, so we know that miners will simply queue transactions. The transactions eligible for block inclusion that pay the highest fee per kilobyte will be confirmed earlier than transactions that pay comparatively lower fees.<ref name="fee_pri" /><br />
<br />
Basic economic theory tells us that increases in price reduce economic demand, ceteris paribus. Assuming that larger blocks would not cause a loss of demand for on-chain transaction processing due to a perceived loss of the network's decentralization and censorship resistance, blocks that are too small to include all pending transactions will result in demand for on-chain transaction processing being less than it would be if blocks were large enough include all pending transactions.<br />
<br />
What happens from there is debated:<br />
<br />
* BitcoinJ lead developer Mike Hearn believes there would be “crashing nodes, a swelling transaction backlog, a sudden spike in double spending, [and] skyrocketing fees.”<ref>[https://medium.com/@octskyward/crash-landing-f5cc19908e32 Crash Landing], Mike Hearn, 7 May 2015</ref><br />
* Bitcoin Foundation chief scientist Gavin Andresen believes that the “average transaction fee paid will rise, people or applications unwilling or unable to pay the rising fees will stop submitting transactions, [and] people and businesses will shelve plans to use Bitcoin, stunting growth and adoption.” <ref>[https://github.com/bitcoin/bitcoin/pull/6341 Bitcoin Core pull #6341], Gavin Andresen, 26 June 2015</ref><br />
* Bitcoin Core developer Pieter Wuille replies to Andresen’s comment above: “Is it fair to summarize this as ‘Some use cases won’t fit any more, people will decide to no longer use the blockchain for these purposes, and the fees will adapt.’? I think that is already happening […] I don’t think we should be afraid of this change or try to stop it.” <ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009098.html The need for larger blocks], Pieter Wuille, 26 June 2015</ref><br />
* Bitcoin Core developer Jeff Garzik writes, "as blocks get full and the bidding war ensues, the bitcoin user experience rapidly degrades to poor. In part due to bitcoin wallet software’s relative immaturity, and in part due to bitcoin’s settlement based design, the end user experience of their transaction competing for block size results in erratic, and unpredictably extended validation times."<ref name="garzik_bip" /><br />
<br />
== Specific Scaling Proposals ==<br />
<br />
=== Andresen-Hearn Block Size Increase Proposals ===<br />
<br />
Questions about the series of related proposals by Gavin Andresen and Mike Hearn to use a hard fork to raise the maximum block size, thereby allowing miners to include more on-chain transactions. As of July 2015, the current focus is [https://github.com/bitcoin/bips/pull/163 BIP101].<br />
<br />
==== What is the major advantage of this proposal? ====<br />
<br />
''Bitcoin can support many more users.'' Assuming earliest possible adoption, 250 bytes per on-chain transaction, 144 blocks per day, and 2 transaction a day per user, Bitcoin can support about,<br />
<br />
* 288,000 users in 2015<br />
* 2,304,000 users in 2016 (800% increase)<br />
* 4,608,000 in 2018 (1,600%)<br />
* 9,216,000 in 2020 (3,200%)<br />
* 18,432,000 in 2022 (6,400%)<br />
* 36,864,000 in 2024 (12,800%)<br />
* 73,728,000 in 2026 (25,600%)<br />
* 147,456,000 in 2028 (51,200%)<br />
* 294,912,000 in 2030 (102,400%)<br />
* 589,824,000 in 2032 (204,800%)<br />
* 1,179,648,000 in 2034 (409,600%<br />
* 2,359,296,000 in 2036 (819,200%)<br />
<br />
==== What is the major disadvantage of this proposal? ====<br />
<br />
''The total cost of remaining decentralized will be high.'' Assuming earliest possible adoption and that the ratio of total users to full node operators remains the same as today, the total estimated amount of work necessary to maintain the decentralized system under the [[#O.28n2.29_network_total_validation_resource_requirements|O(<sup>2</sup>) scaling model]] will be,<br />
<br />
* 100% of today’s work in 2015<br />
* 6,400% in 2016<br />
* 25,600% in 2018<br />
* 102,400% in 2020<br />
* 409,600% in 2022<br />
* 1,638,400% in 2024<br />
* 6,553,600% in 2026<br />
* 26,214,400% in 2028<br />
* 104,857,600% in 2030<br />
* 419,430,400% in 2032<br />
* 1,677,721,600% in 2034<br />
* 6,710,886,400% in 2036<br />
<br />
For example, if the total amount spent on running full nodes today (not counting mining) is $100 thousand per year, the estimated cost for the same level of decentralization in 2036 will be $6.7 trillion per year if validation costs stay the same. (They'll certainly go down, but algorithmic and hardware improvements probably won't eliminate an approximate 6,710,886,400% cost increase.)<br />
<br />
==== What are the dangers of the proposed hard fork? ====<br />
<br />
Under the current proposal, 75% of miners must indicate that they agree to accept blocks up to 8 MB in size.<ref name="bip101">[https://github.com/bitcoin/bips/pull/163 BIP101], Gavin Andresen, 24 June 2016</ref> After the change goes into effect, if any miner creates a block larger than 1 MB, all nodes which have not upgraded yet will reject the block.<ref>[https://bitcoin.org/en/developer-guide#consensus-rule-changes Consensus rule changes], Bitcoin.org Developer Guide</ref><br />
<br />
If all full nodes have upgraded, or very close to all nodes, there should be no practical effect. If a significant number of full nodes have not upgraded, they will continue using a different block chain than the upgraded users, with the following consequences:<br />
<br />
* Bitcoins received from before the fork can be spent twice, once on both sides of the fork. This creates a high double spend risk.<br />
* Bitcoins received after the fork are only guaranteed to be spendable on the side of the fork they were received on. This means some users will have to lose money to restore Bitcoin to a single chain.<br />
<br />
Users of hosted wallets (Coinbase, BlockChain.info, etc.) will use whatever block chain their host chooses. Users of lightweight P2P SPV wallets will use the [[Thin Client Security|longest chain they know of]], which may not be the actual longest chain if they only connect to nodes on the shorter chain. Users of non-P2P SPV wallets, like Electrum, will use whatever chain is used by the server they connect to.<br />
<br />
If a bad hard fork like this happens, it will likely cause large-scale confusion and make Bitcoin very hard to use until the situation is resolved.<br />
<br />
==== What is the deployment schedule for BIP 101? ====<br />
<br />
* The patch needs to be accepted into Bitcoin Core, Bitcoin XT, or both.<br />
* If accepted into Bitcoin Core, miners using that software will need to upgrade (this probably requires a new released version of Bitcoin Core). If accepted only into Bitcoin XT, miners will need to switch to using XT.<br />
* After 75% of miners have upgraded, 8MB blocks will become allowed at the the latest of (1) 11 January 2016 or (2) two weeks after the 75% upgrade threshold.<ref name="bip101" /><br />
* After the effective date has passed, any miner may create a block larger than 8MB. When a miner does this, upgraded full nodes will accept that block and non-upgraded full nodes will reject it, forking the network.<ref name="bip101" /> See [[#What_are_the_dangers_of_the_proposed_hard_fork.3F|hard fork dangers]] for what his might mean.<br />
<br />
==== Will miners go straight from 1 MB blocks to 8 MB blocks? ====<br />
<br />
That would be highly unlikely. Uploading an 8 MB block currently takes significantly more time than uploading a 1 MB block<ref name="rusty_dsl">[http://rusty.ozlabs.org/?p=509 Mining on a home DSL connection test results], Rusty Russell, 19 June 2015</ref>, even with the roughly 25x reduction in size available from use of Matt Corallo’s block relay network.<ref name="block_relay_net" /><br />
<br />
The longer it takes to upload a block, the higher the risk it will become a stale block—meaning the miner who created it will not receive the block subsidy or transaction fees (currently about 25 BTC per block).<br />
<br />
However, if technology like Invertible Bloom Lookup Tables (IBLTs) is deployed and found to work as expected<ref name="iblt">[https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2 O(1) block propagation], Gavin Andresen, 8 August 2014</ref>, or if mining [[#What_is_the_most_efficient_way_to_scale_Bitcoin.3F|centralizes further]], adding additional transactions may not have a significant enough cost to discourage miners from creating full blocks. In that case, blocks will be filled as soon as there are enough people wanting to make transactions paying the default relay fee<ref>[https://github.com/bitcoin/bitcoin/pull/3305 Bitcoin Core pull #3305 dropping default fees], Mike Hearn, 22 November 2013</ref> of 0.00001000 BTC/kilobyte.<br />
<br />
==== What tests have been performed related to this proposal? ====<br />
<br />
* '''20MB block processing''' (Gavin Andresen) “if we increased the maximum block size to 20 megabytes tomorrow, and every single miner decided to start creating 20MB blocks and there was a sudden increase in the number of transactions on the network to fill up those blocks… the 0.10.0 version of [Bitcoin Core] would run just fine.”<ref>[http://gavintech.blogspot.com/2015/01/twenty-megabytes-testing-results.html Twenty megabyte block testing], Gavin Andresen, 20 January 2015</ref> (ellipses in original)<br />
* '''Mining &amp; relay simulation''' (Gavin Andresen) “if blocks take 20 seconds to propagate, a network with a miner that has 30% of the hashing power will get 30.3% of the blocks.”<ref>[http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners Are bigger blocks better for bigger miners?], Gavin Andresen, 22 May 2015</ref><br />
* '''Mining on a home DSL connection''' (Rusty Russell) “Using the rough formula of 1-exp(-t/600), I would expect orphan rates of 10.5% generating 1MB blocks, and 56.6% with 8MB blocks; that’s a huge cut in expected profits.”<ref name="rusty_dsl" /><br />
* '''Mining centralization pressure''' (Pieter Wuille) “[This] does very clearly show the effects of larger blocks on centralization pressure of the system.”<ref name="wuille_centralization">[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008581.html Mining centralization pressure from non-uniform propagation speed], Pieter Wuille, 12 June 2015</ref><br />
<br />
<br />
=== Garzik Miner Block Size Voting Proposal (AKA BIP100) ===<br />
<br />
''Note, BIP 100 is the marketing name for this proposal. No BIP number<br />
has yet been publicly requested, and the number assigned is unlikely to<br />
be 100.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-May/005756.html<br />
Prenumbered BIP naming], Gregory Maxwell, 12 May 2014</ref>''<br />
<br />
Questions related to Jeff Garzik's proposal<ref name="garzik_bip">[http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf Draft BIP: decentralized economic policy], Jeff Garzik, 12 June 2015 (revised 15 June 2015)</ref> to allow miners to vote on raising and lowering the maximum block size.<br />
<br />
==== What does this proposal do? ====<br />
<br />
# It creates a one-time hard fork that does not automatically change the maximum block size.<br />
<br />
# It allows miners to vote to increase or decrease the maximum block size within the range of 1MB to 32MB. These changes are neither hard forks nor soft forks, but simply rules that all nodes should know about after the initial hard fork.<br />
<br />
==== Does it reduce the risk of a hard fork? ====<br />
<br />
Hard forks are most dangerous when they're done without strong<br />
consensus.<ref name="garzik_bip" /><ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008779.html Consensus changes are not about making a change to the software],<br />
Pieter Wuille, 18 June 2015</ref><br />
<br />
If Garzik's proposal gains strong consensus, it will be as safe as possible<br />
for a hard fork and it will allow increasing the block size up to 32 MB<br />
without any additional risk of a fork.<br />
<br />
==== Why is it limited to 32 megabytes? ====<br />
<br />
According to the draft BIP, "the 32 MB hard fork is largely coincidental -- a whole network upgrade at 32 MB was likely needed anyway."<br />
<br />
=== Lightning Network ===<br />
<br />
Questions related to using the proposed [http://lightning.network/ Lightning network] as a way to scale the number of users Bitcoin can support.<br />
<br />
==== How does transaction security differ from that of Bitcoin? ====<br />
<br />
Transactions on the proposed Lightning network use Bitcoin transactions exclusively to transfer bitcoins<ref name="russell_lightning1">[http://rusty.ozlabs.org/?p=450 Lightning Networks: Part I], Rusty Russell, 30 March 2015</ref>, and so the same security as regular Bitcoin transactions is provided when both a Lightning hub and client are cooperating.<br />
<br />
When a Lightning hub or client refuses to cooperate with the other (maybe because they accidentally went offline), the other party can still receive their full 100% bitcoin balance by closing the payment channel—but they must first wait for a defined amount of time mutually chosen by both the hub and client.<ref>[http://rusty.ozlabs.org/?p=462 Lightning Networks: Part II], Rusty Russell, 1 April 2015</ref><br />
<br />
If one party waits too long to close the payment channel, the other party may be able to steal bitcoins. However, it is possible to delegate the task of closing the channel in an emergency to an unlimited number of hubs around the Internet, so closing the channel on time should be easy.<ref name="russell_lightning4">[http://rusty.ozlabs.org/?p=477 Lightning Networks: Part IV], Rusty Russell, 8 April 2015</ref><br />
<br />
In summary, provided that payment channels are closed on time, the worst that can happen to users is that they may have to wait a few weeks for a channel to fully close before spending the bitcoins they received from it. Their security is otherwise the same as with regular Bitcoin.<br />
<br />
For Lightning hubs, security is slightly worse in the sense that they need to keep a potentially-large amount of funds in a hot wallet<ref name="lightning_paper">[http://lightning.network/lightning-network-paper-DRAFT-0.5.pdf Lightning Network (Draft 0.5)], Section 6.3: Coin Theft via Hacking, Joseph Poon and Thaddeus Dryja</ref>, so they can’t take advantage of the anti-hacking protection offered by cold wallets. Otherwise, Lightning hubs have the same security as clients.<br />
<br />
==== When will Lightning be ready for use? ====<br />
<br />
Lightning requires a basic test implementation (work underway<ref>[https://lists.blockstream.com/pipermail/lightning-dev/2015-June/000018.html Lightning first steps], Rusty Russell, 13 June 2015</ref>), several soft-fork changes to the Bitcoin protocol (work underway<ref>[https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65: CheckLockTimeVerify], Peter Todd, 1 October 2014</ref><ref>[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68: Consensus-enforced transaction replacement], Mark Friedenbach, 28 May 2015</ref>, and wallets need to be updated to support the Lightning network protocol.<ref name="russell_lightning4" /><br />
<br />
Dr. Adam Back has said, "I expect we can get something running inside a year."<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009242.html Reply to Andresen regarding Lightning], Dr. Adam Back, 28 June 2015</ref><br />
<br />
==== Doesn’t Lightning require bigger blocks anyway? ====<br />
<br />
Lightning is block-size neutral. It requires one on-chain transaction to open a channel between a hub and a client, and one on-chain transaction to close a channel.<ref name="russell_lightning1" /> In between it can support an unlimited number of transactions between anyone on the Lightning network.<ref name="lightning_paper" /><br />
<br />
Using the numbers from the Lightning presentation<ref name="lightning_slides">[http://lightning.network/lightning-network.pdf Lightning presentation], Joseph Poon, 23 February 2015</ref>, if people open and close a plausible two channels a year, Lightning can support about 52 million users with the current one-megabyte limit—and each user can make an unlimited number of transactions. Currently, assuming people make an average of only two Bitcoin transactions a day, basic Bitcoin can support only 288,000 users.<br />
<br />
Under these assumptions, Lightning is 180 times (17,900%) more efficient than basic Bitcoin.<br />
<br />
Presumably, if around 30 million people are using Bitcoin via Lightning so that capacity is called into question, it will not be difficult to find consensus to double the block size to two megabytes and bring user capacity up to 105 million. The same goes for later increases to 200 million (4MB), 400 million (8MB), 800 million (16MB), 1.6 billion (32 MB), 3.2 billion (64MB), and all 7 billion living humans (133MB). In each case, all Lightning network participants get unlimited transactions to the other participants.<br />
<br />
For basic Bitcoin to scale to just 2 transactions a day for 7 billion people would require 24-gigabyte blocks.<ref name="lightning_slides" /><br />
<br />
=== Sidechains ===<br />
<br />
==== Real quick, what are sidechains? ====<br />
<br />
Block chains that are separate from Bitcoin’s block chain, but which allow you to receive and spend bitcoins using a two-way peg (2WP).<ref name="sidechains_paper">[https://www.blockstream.com/sidechains.pdf Sidechains paper], Adam Back et al., 22 October 2014</ref> (Although a sidechain can never be more secure than the Bitcoin block chain.<ref>[https://www.reddit.com/r/Bitcoin/comments/39r85g/sidechain_hate/cs5spbg Security limitations of pegged chains], Gregory Maxwell, 14 June 2015</ref>)<br />
<br />
==== Are sidechains a scaling option? ====<br />
<br />
No. Sidechains have the same fundamental scaling problems as Bitcoin does. Moving some transactions to sidechains simply moves some problems elsewhere on the network—the total difficulty of the problem remains the same.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008617.html Sidechains not a direct means for solving any of the scaling problems Bitcoin has], Pieter Wuille, 13 June 2015</ref><br />
<br />
==== But couldn’t I create a sidechain that had 100 GB blocks? ====<br />
<br />
Certainly, sidechain code is open source<ref>[https://github.com/ElementsProject/elements Elements Project]</ref>—so you can create your own sidechain. But you’d still have the difficulty of finding people who are willing to validate 100 GB blocks with their own full nodes.<br />
<br />
==== Do sidechains require a hard fork? ====<br />
<br />
No. Federated sidechains, such as have already been implemented<ref>[https://github.com/ElementsProject/elements/tree/alpha Elements Alpha]</ref>, don’t require any changes to the Bitcoin consensus rules. Merged-mined sidechains, which have not been implemented yet, do require a backwards-compatible soft fork in order to transfer funds between Bitcoin and the sidechain.<ref name="sidechains_paper" /><br />
<br />
== References ==<br />
<references /></div>Amincdhttps://en.bitcoin.it/w/index.php?title=Scalability_FAQ&diff=60393Scalability FAQ2016-02-14T16:00:17Z<p>Amincd: /* What happens if blocks aren't big enough to include all pending transactions? */</p>
<hr />
<div>Answers to commonly-asked questions and concerns about scaling Bitcoin, including “level 1” solutions such as increasing the block size and “level 2” solutions such as the proposed Lightning network.<br />
<br />
== Background ==<br />
<br />
Questions about how Bitcoin currently works (related to scaling) as well as questions about the technical terminology related to the scaling discussion.<br />
<br />
=== What is the short history of the block size limit? ===<br />
<br />
''Note: the software now called Bitcoin Core was previously simply called “Bitcoin”.<ref>[https://bitcoin.org/en/release/v0.9.0#rebranding-to-bitcoin-core Bitcoin Core 0.9.0 release notes], Bitcoin.org, 19 March 2014</ref> To avoid confusion with the Bitcoin system, we’ll use the Bitcoin Core name.''<br />
<br />
Bitcoin Core was initially released without an explicit block size limit. However, the code did limit network messages to a maximum of 32 MiB, setting an effective upper bound on block size.<ref>[https://bitcointalk.org/index.php?topic=68121 Earliest known Bitcoin code], <code>src/main.h:17</code></ref><br />
<br />
Around 15 July 2010, Satoshi Nakamoto changed Bitcoin Core’s mining code so that it wouldn’t create any blocks larger than 990,000 bytes.<ref>[https://github.com/bitcoin/bitcoin/commit/a30b56ebe76ffff9f9cc8a6667186179413c6349 Bitcoin Core commit a30b56e], Satoshi Nakamoto, 15 July 2010</ref><br />
<br />
Two months later on 7 September 2010, Nakamoto changed Bitcoin Core’s consensus rules to reject blocks larger than 1,000,000 bytes (1 megabyte) if their block height was higher than 79,400.<ref>[https://github.com/bitcoin/bitcoin/commit/8c9479c6bbbc38b897dc97de9d04e4d5a5a36730 Bitcoin Core commit 8c9479c], Satoshi Nakamoto, 7 September 2010</ref> (Block 79,400 was later produced on 12 September 2010.<ref>[https://www.biteasy.com/blockchain/blocks/000000000021d821ec06be7173f413690bc5c4bc648dfa70b3b6763236f055b7 Block height 79400], dated 12 September 2010</ref>)<br />
<br />
Neither the July nor the September commit message explains the reason for the limit, although the careful attempt to prevent a fork may indicate Nakamoto didn’t consider it an emergency.<br />
<br />
Nakamoto’s subsequent statements supported raising the block size at a later time<ref>[https://bitcointalk.org/index.php?topic=1347.msg15139#msg15139 Increasing the block size when needed], Satoshi Nakamoto, 3 October 2010</ref>, but he never publicly specified a date or set of conditions for the raise.<br />
<br />
Statements by Nakamoto in the summer of 2010 indicate he believed Bitcoin could scale to block sizes far larger 1 megabyte. For example, on 5 August 2010, he wrote that "[W]hatever size micropayments you need will eventually be practical. I think in 5 or 10 years, the bandwidth and storage will seem trivial" and "[microtransactions on the blockchain] can become more practical ... if I implement client-only mode and the number of network nodes consolidates into a smaller number of professional server farms" <ref>[https://bitcointalk.org/index.php?topic=532.msg6306#msg6306 the number of network nodes consolidates into a smaller number of professional server farms]</ref>. <br />
<br />
These statements suggest that the intended purpose of the 1 megabyte limit was not to keep bandwidth and storage requirements for running a Bitcoin node low enough to be practical for personal computers and consumer-grade internet connections, and that the limit would be lifted to accommodate greater demand for transactional capacity.<br />
<br />
=== What is this Transactions Per Second (TPS) limit? ===<br />
<br />
The current block size limit is 1,000,000 bytes (1 megabyte)<ref>[https://github.com/bitcoin/bitcoin/blob/41076aad0cbdfa4c4cf376e345114a5c29086f81/src/consensus/consensus.h#L10 <code>MAX_BLOCK_SIZE</code>], retrieved 2 July 2015</ref>, although a small amount of that space (such as the block header) is not available to store transactions.<ref>[https://bitcoin.org/en/developer-reference#serialized-blocks Block serialization description], Bitcoin.org Developer Reference</ref><br />
<br />
Bitcoin transactions vary in size depending on multiple factors, such as whether they’re spending single-signature inputs or a multiple signature inputs, and how many inputs and outputs they have.<br />
<br />
The simple way to calculate the number of Transactions Per Second (TPS) Bitcoin can handle is to divide the block size limit by the expected average size of transactions, divided by the average number of seconds between blocks (600). For example, if you assume average transactions are 250 bytes,<br />
<br />
<pre>6.6 TPS = 1,000,000 / 250 / 600</pre><br />
<br />
There seems to be general agreement that Bitcoin in 2015 can handle about 3 TPS with the current average size of transactions.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/007986.html Max TPS based on current average transaction size], Mike Hearn, 8 May 2015</ref><ref name="maxwell_not_proposing">[https://www.reddit.com/r/Bitcoin/comments/39yaod/bitcoinorg_position_on_hard_forks/cs7qz5c "No one proposing 3 TPS forever"], Gregory Maxwell, 15 June 2015</ref><br />
<br />
Both old estimates<ref>[[Scalability]], Bitcoin Wiki, retrieved 7 July<br />
2015</ref> and new estimates<ref name="garzik_bip" /> place the<br />
theoretical maximum at 7 TPS with current Bitcoin consensus rules<br />
(including the 1MB block size limit).<br />
<br />
=== What do devs mean by the scaling expressions O(1), O(n), O(n<sup>2</sup>), etc…? ===<br />
<br />
[https://en.wikipedia.org/wiki/Big_O_notation Big O notation] is a shorthand used by computer scientists to describe how well a system scales. Such descriptions are rough approximations meant to help predict potential problems and evaluate potential solutions; they are not usually expected to fully capture all variables.<br />
<br />
* '''O(1)''' means a system has roughly the same properties no matter how big it gets.<br />
* '''O(n)''' means that a system scales linearly: doubling the number of things (users, transactions, etc.) doubles the amount of work.<br />
* '''O(n<sup>2</sup>)''' means that a system scales quadratically : doubling (2x) the number of things quadruples (4x) the amount of work. Often written O(n^2) is places without convenient superscripts.<br />
* Additional examples may be found in the [https://en.wikipedia.org/wiki/Big_O_notation#Orders_of_common_functions Wikipedia article]<br />
<br />
The following subsections show cases where big O notation has been applied to the scaling Bitcoin transaction volume.<br />
<br />
==== O(1) block propagation ====<br />
<br />
Bitcoin Core currently relays unconfirmed transactions and then later relays blocks containing many of the same transactions. This redundant relay can be eliminated to allow miners to propagate large blocks very quickly to active network nodes, and would also significantly reduce miner need for peak bandwidth. Currently most miners use a network<ref name="block_relay_net">[http://bitcoinrelaynetwork.org/ Matt Corallo's block relay network]</ref> that is about 25x more efficient than stock Bitcoin Core<ref>[https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2#i-know-that-you-know IBLT design document], Gavin Andresen, 11 August 2014</ref> and almost equally as effective as O(1) block propagation for current block sizes.<br />
<br />
=== What’s the difference between on-chain and off-chain transactions? ===<br />
<br />
On-chain Bitcoin transactions are those that appear in the Bitcoin block chain. Off-chain transactions are those that transfer ownership of bitcoins without putting a transaction on the block chain.<br />
<br />
Common and proposed off-chain transactions include:<br />
<br />
* '''Exchange transactions:''' when you buy or sell bitcoins, the exchange tracks ownership in a database without putting data in the block chain. Only when you deposit or withdraw bitcoins does the transaction appear on the block chain.<br />
* '''Web wallet internal payments:''' many web wallets allow users of the service to pay other users of the same service using off-chain payments. For example, when one Coinbase user pays another Coinbase user.<br />
* '''Tipping services:''' most tipping services today, such as ChangeTip, use off-chain transactions for everything except deposits and withdrawals.<ref>[https://www.changetip.com/fees ChangeTip fees], retrieved 3 July 2015</ref><br />
* '''Payment channels:''' channels are started using one on-chain transaction and ended using a second on-chain transaction.<ref>[https://bitcoin.org/en/developer-guide#micropayment-channel Micropayment channels], Bitcoin.org Developer Guide</ref> In between can be an essentially unlimited number of off-chain transactions as small as a single satoshi (1/100,000,000th of a bitcoin). Payment channels include those that [https://bitcoinj.github.io/working-with-micropayments exist today] as well as proposed hub-and-spoke channels and the more advanced [http://lightning.network/ Lightning network].<br />
<br />
Approximately 90% to 99% of all bitcoin-denominated payments today are made off-chain.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008844.html Pure off-chain is a weak form of layer 2], Dr. Adam Back, 19 June 2015</ref><br />
<br />
=== What is a fee market? ===<br />
<br />
When you create a Bitcoin transaction, you have the option to pay a [[transaction fee]]. If your software is flexible, you can pay anything from zero fees (a free transaction) to 100% of the value of the transaction (spend-to-fees). This fee is comparable to a tip. The higher it is, the bigger the incentive of the miners to incorporate your transaction into the next block.<br />
<br />
When miners assemble a block, they are free to include whatever transactions they wish. They usually include as many as possible up to the maximum block size and then prioritize the transactions that pay the most fees per kilobyte of data.<ref name="fee_pri">[https://bitcointalk.org/index.php?topic=95837.0 Fee prioritization patch], Gavin Andresen, 26 July 2012</ref> This confirms higher-fee transactions before lower-fee transactions. If blocks become full on a regular basis, users who pay a fee that's too small will have to wait a longer and longer time for their transactions to confirm. At this point, a demand-driven fee market may arise where transactions that pay higher fees get confirmed significantly faster than transactions that pay low fees.<ref name="todd_coinwallet">[https://gist.github.com/petertodd/8e87c782bdf342ef18fb Comments on the CoinWallet.eu tx-flood stress-test], Peter Todd, 22 June 2015</ref><ref name="garzik_bip" /><br />
<br />
In a competitive market, prices are driven by supply and demand and the emerging equilibrium price asymptotically approaches marginal costs over time. However, the current version of Bitcoin limits the supply to 1 MB per block, only allowing demand to adjust. To establish a free market, one would need to come up with a mechanism that allows the number of included transactions per block to adjust dynamically as well. The design of such a mechanism, however, is not trivial. Simply allowing individual miners to include as many transactions as they want is problematic due to the externalities<ref name="exernality">[https://en.wikipedia.org/wiki/Externality Definition of externality], Wikipedia, 26 January 2016</ref> of including additional blocks and explained further in section [[#Should miners be allowed to decide the block size?|'should miners be allowed to decide the block size?']] .<br />
<br />
=== What is the most efficient way to scale Bitcoin? ===<br />
<br />
Remove its decentralization properties, specifically decentralized mining and decentralized full nodes. Mining wastes enormous amounts of electricity to provide a decentralized ledger and full nodes waste an enormous amount of bandwidth and CPU time keeping miners honest.<br />
<br />
If users instead decided to hand authority over to someone they trusted, mining and keeping miners honest wouldn’t be needed. This is how Visa, MasterCard, PayPal, and the rest of the centralized payment systems works—users trust them, and they have no special difficulty scaling to [[scalability|millions of transactions an hour]]. It’s very efficient; it isn’t decentralized.<br />
<br />
=== What is a hard fork, and how does it differ from other types of forks? ===<br />
<br />
The word fork is badly overloaded in Bitcoin development.<br />
<br />
* '''[[hardfork|Hard fork]]:''' a change to the system which is not backwards compatible. Everyone needs to upgrade or things can go wrong.<br />
* '''[[softfork|Soft fork]]:''' a change to the system which is backwards compatible as long as a majority of miners enforce it. Full nodes that don’t upgrade have their security reduced.<br />
* '''Chain fork:''' when there are two are more blocks at the same height on a block chain. This typically happens a few times a week by accident, but it can also indicate more severe problems.<br />
* '''[https://en.wikipedia.org/wiki/Fork_%28software_development%29 Software fork]:''' using the code from an open source project to create a different project.<br />
* '''[https://help.github.com/articles/fork-a-repo/ Git/GitHub fork]:''' a way for developers to write and test new features before contributing them to a project.<br />
<br />
(There are other types of software-related forks, but they don’t tend to cause as much confusion.)<br />
<br />
=== What are the block size soft limits? ===<br />
<br />
Bitcoin Core has historically come pre-configured to limit blocks it mines to certain sizes.<ref name="fee_pri" /> These “limits” aren’t restrictions placed on miners by other miners or nodes, but rather configuration options that help miners produce reasonably-sized blocks.<br />
<br />
Miners can change their soft limit size (up to 1 MB) using <code>-blockmaxsize=&lt;size&gt;</code><br />
<br />
Default soft limits at various times:<br />
<br />
* '''July 2012:''' <code>-blockmaxsize</code> option created and set to default 250 KB soft limit<ref>[https://github.com/bitcoin/bitcoin/commit/c555400ca134991e39d5e3a565fcd2215abe56f6 Bitcoin Core commit c555400], Gavin Andresen, 12 July 2012</ref><br />
* '''November 2013:''' Raised to 750KB<ref>[https://github.com/bitcoin/bitcoin/commit/ad898b40aaf06c1cc7ac12e953805720fc9217c0 Bitcoin Core commit ad898b40], Gavin Andresen, 27 November 2013</ref><br />
* '''June 2015:''' Raise to 1 MB suggested<ref>[https://github.com/bitcoin/bitcoin/pull/6231 Bitcoin Core pull #6231], Chris Wheeler, 4 June 2015</ref><br />
<br />
== General Block Size Increase Theory ==<br />
<br />
Questions about increasing the block size in general, not related to any<br />
specific proposal.<br />
<br />
==== Why are some people in favor of keeping the block size at 1 MB forever? ====<br />
<br />
It is commonly claimed<ref name="garzik_bip" /><ref>[https://epicenterbitcoin.com/podcast/082/ Epicenter Bitcoin podcast #82], Mike Hearn (interviewed), 8 June 2015</ref> that there are people opposed to ever raising the maximum block size limit, but no Bitcoin developers have suggested keeping the maximum block size at one megabyte forever.<ref name="maxwell_not_proposing" /><br />
<br />
All developers support raising the maximum size at some point<ref>[https://www.reddit.com/r/Bitcoin/comments/39kqzs/how_about_a_softfork_optin_blocksize_increase/cs5hj8l Nothing magic about 1MB], Dr. Adam Back, 13 June 2015</ref><ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008328.html Regarding size-independent new block propagation], Pieter Wuille, 28 May 2015</ref>—they just disagree about whether now is the correct time.<br />
<br />
==== Should miners be allowed to decide the block size? ====<br />
<br />
A block may include as little as a single transaction, so miners can always restrict block size. Letting miners choose the maximum block size is more problematic for several reasons:<br />
<br />
# '''Miners profit, others pay the cost:''' bigger blocks earn miners more fees, but miners don’t need to store those blocks for more than a few days.<ref>[https://github.com/bitcoin/bitcoin/pull/5863 Bitcoin Core pull #5863 adding pruning functionality], Suhas Daftuar et al., 6 March 2015</ref> Other users who want full validation security, or who provide services to lightweight wallets, pay the costs of downloading and storing those larger blocks.<br />
# '''Bigger miners can afford more bandwidth:''' each miner needs to download every transaction that will be included in block,<ref name="maxwell_correcting_assumptions" /> which means that they all need to pay for high-speed connections. However, a miner with 8.3% of total hash rate can take that cost out of the about 300 BTC they make a day, while a miner with only 0.7% of total hash rate has to take that cost out of only 25 BTC a day. This means bigger miners may logically choose to make bigger blocks even though it may further centralize mining.<br />
# '''Centralized hardware production:''' only a few companies in the world produce efficient mining equipment, and many of them have chosen to stop selling to the public.<ref>[http://blogs.wsj.com/venturecapital/2014/09/05/for-kncminer-time-to-forget-selling-bitcoin-machines-to-at-home-miners/ KnCMiner to stop selling to home miners], Wall Street Journal, Yuliya Chernova, 5 September 2014</ref> This prevents ordinary Bitcoin users from participating in the process even if they were willing to pay for mining equipment.<br />
# '''Voting by hash rate favors larger miners:''' voting based on hash rate allows the current hash rate majority (or super-majority) to enforce conditions on the minority. This is similar to a lobby of large businesses being able to get laws passed that may hurt smaller businesses.<ref>[https://www.reddit.com/r/Bitcoin/comments/39kzyt/draft_bip_100_soft_fork_block_size_increase/cs5gvak Miners choosing the block size limit is ill-advised], Meni Rosenfeld, 13 June 2015</ref><br />
# '''Miners may not care about users:''' this was demonstrated during the [[July 2015 Forks]] where even after miners lost over $50,000 USD in income from mining invalid chains, and even after they were told that long forks harm users, they continued to mine improperly.<ref>[https://bitcointalk.org/index.php?topic=700411.msg11790734#msg11790734 Intention to continue SPV mining], Wang Chun, 4 July 2015</ref><br />
<br />
However, there are also possible justifications for letting miners choose the block size:<br />
<br />
# '''Authenticated participants:''' miners are active participants in Bitcoin, and they can prove it by adding data to the blocks they create.<ref>[https://bitcoin.org/en/developer-reference#term-coinbase-field Coinbase field], Bitcoin.org Developer Reference</ref> It is much harder to prove people on Reddit, BitcoinTalk, and elsewhere are real people with an active stake in Bitcoin.<br />
# '''Bigger blocks may cost miners:''' small miners and poorly-connected miners are at a disadvantage if larger blocks are produced<ref name="wuille_centralization" />, and even large and well-connected miners may find that large blocks reduce their profit percentage if the cost of bandwidth rises too high or their stale rate increases.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008355.html F2Pool block size concerns], Chun Wang, 29 May 2015</ref><br />
<br />
==== How could a block size increase affect user security? ====<br />
<br />
Bitcoin’s security is highly dependent on the number of active users who protect their bitcoins with a full node like Bitcoin Core. The more active users of full nodes, the harder it is for miners to trick users into accepting fake bitcoins or other frauds.<ref>[https://medium.com/@lopp/bitcoin-nodes-how-many-is-enough-9b8e8f6fd2cf Bitcoin nodes: how many is enough?], Jameson Lopp, 7 June 2015</ref><br />
<br />
Full nodes need to download and verify every block, and most nodes also store blocks plus relay transactions, full blocks, and filtered blocks to other users on the network. The bigger blocks become, the more difficult it becomes to do all this, so it is expected that bigger blocks will both reduce the number of users who currently run full nodes and suppress the number of users who decide to start running a full node later.<ref>[https://www.reddit.com/r/Bitcoin/comments/3bae2d/amir_taaki_on_raising_the_block_size_a_lot_of/cslcgmw Block size increases-only will create problems], Dr. Adam Back, 28 June 2015</ref><br />
<br />
In addition, full blocks may increase mining centralization<ref name="wuille_centralization" /> at a time when mining is already so centralized that it makes it easy to reverse transactions which have been confirmed multiple times.<ref>[http://bitcoin.stackexchange.com/questions/32562/when-to-worry-about-1-confirmation-payments/32564#32564 When to worry about one-confirmation payments], David A. Harding, 17 November 2014</ref><br />
<br />
==== How could larger blocks affect proof-of-work (POW) security? ====<br />
<br />
Proof of work security is dependent on how much money miners spend on mining equipment. However, to effectively mine blocks, miners also need to spend money on bandwidth to receive new transactions and blocks created by other miners; CPUs to validate received transactions and blocks; and bandwidth to upload new blocks. These additional costs don’t directly contribute to POW security.<ref name="maxwell_correcting_assumptions">[https://www.reddit.com/r/Bitcoin/comments/39tgno/letting_miners_vote_on_the_maximum_block_size_is/cs6rek5 Correcting wrong assumptions about mining], Gregory Maxwell, 15 June 2015</ref><br />
<br />
As block sizes increase, the amount of bandwidth and CPU required also increases. If block sizes increase faster than the costs of bandwidth and CPU decrease, miners will have less money for POW security relative to the gross income they earn.<br />
<br />
In addition, larger blocks have a higher risk of becoming stale (orphaned)<ref name="rusty_dsl" />, which directly correlates to lost POW security. For example, if the network average stale rate is 10%, then 10% of POW performed isn't protecting transactions on the block chain.<br />
<br />
Conversely, larger blocks that result in a lower per transaction fee can increase the demand for on-chain transactions, and result in total transaction fees earned by miners increasing despite a lower average transaction fee. This would increase network security by increasing the revenue that supports Proof of Work generation. <br />
<br />
Without an increase in the block size from 1 megabyte, Bitcoin needs $1.50 worth of BTC paid in fees per transaction once block subsidies disappear to maintain current mining revenue and economic expenditure on network security. The required fee per transaction for maintaining current economic expenditure levels once the subsidy disappears decreases as the block size, and with it the maximum on-chain transaction throughput, increases. <br />
<br />
As a result of the sensitivity of demand to price increases, growth in the Bitcoin economy, and thus growth in the fees paid to secure the Bitcoin network, could be stunted if the block size is not allowed to increase sufficiently.<br />
<br />
=== What happens if blocks aren't big enough to include all pending transactions? ===<br />
<br />
This is already the case more often than not<ref>[http://statoshi.info/dashboard/db/transactions?from=1433297061121&to=1435889061123 Statoshi.info mempool queue June to July 2015]</ref>, so we know that miners will simply queue transactions. The transactions eligible for block inclusion that pay the highest fee per kilobyte will be confirmed earlier than transactions that pay comparatively lower fees.<ref name="fee_pri" /><br />
<br />
Basic economic theory tells us that increases in price reduce economic demand, ceteris paribus. Assuming that larger blocks would not cause a loss of demand for on-chain transaction processing due to a perceived loss of the network's decentralization and censorship resistance, blocks that are too small to include all pending transactions will result in demand for on-chain transaction processing being less than it would be if blocks were large enough include all pending transactions.<br />
<br />
What happens from there is debated:<br />
<br />
* BitcoinJ lead developer Mike Hearn believes there would be “crashing nodes, a swelling transaction backlog, a sudden spike in double spending, [and] skyrocketing fees.”<ref>[https://medium.com/@octskyward/crash-landing-f5cc19908e32 Crash Landing], Mike Hearn, 7 May 2015</ref><br />
* Bitcoin Foundation chief scientist Gavin Andresen believes that the “average transaction fee paid will rise, people or applications unwilling or unable to pay the rising fees will stop submitting transactions, [and] people and businesses will shelve plans to use Bitcoin, stunting growth and adoption.” <ref>[https://github.com/bitcoin/bitcoin/pull/6341 Bitcoin Core pull #6341], Gavin Andresen, 26 June 2015</ref><br />
* Bitcoin Core developer Pieter Wuille replies to Andresen’s comment above: “Is it fair to summarize this as ‘Some use cases won’t fit any more, people will decide to no longer use the blockchain for these purposes, and the fees will adapt.’? I think that is already happening […] I don’t think we should be afraid of this change or try to stop it.” <ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009098.html The need for larger blocks], Pieter Wuille, 26 June 2015</ref><br />
* Bitcoin Core developer Jeff Garzik writes, "as blocks get full and the bidding war ensues, the bitcoin user experience rapidly degrades to poor. In part due to bitcoin wallet software’s relative immaturity, and in part due to bitcoin’s settlement based design, the end user experience of their transaction competing for block size results in erratic, and unpredictably extended validation times."<ref name="garzik_bip" /><br />
<br />
== Specific Scaling Proposals ==<br />
<br />
=== Andresen-Hearn Block Size Increase Proposals ===<br />
<br />
Questions about the series of related proposals by Gavin Andresen and Mike Hearn to use a hard fork to raise the maximum block size, thereby allowing miners to include more on-chain transactions. As of July 2015, the current focus is [https://github.com/bitcoin/bips/pull/163 BIP101].<br />
<br />
==== What is the major advantage of this proposal? ====<br />
<br />
''Bitcoin can support many more users.'' Assuming earliest possible adoption, 250 bytes per on-chain transaction, 144 blocks per day, and 2 transaction a day per user, Bitcoin can support about,<br />
<br />
* 288,000 users in 2015<br />
* 2,304,000 users in 2016 (800% increase)<br />
* 4,608,000 in 2018 (1,600%)<br />
* 9,216,000 in 2020 (3,200%)<br />
* 18,432,000 in 2022 (6,400%)<br />
* 36,864,000 in 2024 (12,800%)<br />
* 73,728,000 in 2026 (25,600%)<br />
* 147,456,000 in 2028 (51,200%)<br />
* 294,912,000 in 2030 (102,400%)<br />
* 589,824,000 in 2032 (204,800%)<br />
* 1,179,648,000 in 2034 (409,600%<br />
* 2,359,296,000 in 2036 (819,200%)<br />
<br />
==== What is the major disadvantage of this proposal? ====<br />
<br />
''The total cost of remaining decentralized will be high.'' Assuming earliest possible adoption and that the ratio of total users to full node operators remains the same as today, the total estimated amount of work necessary to maintain the decentralized system under the [[#O.28n2.29_network_total_validation_resource_requirements|O(<sup>2</sup>) scaling model]] will be,<br />
<br />
* 100% of today’s work in 2015<br />
* 6,400% in 2016<br />
* 25,600% in 2018<br />
* 102,400% in 2020<br />
* 409,600% in 2022<br />
* 1,638,400% in 2024<br />
* 6,553,600% in 2026<br />
* 26,214,400% in 2028<br />
* 104,857,600% in 2030<br />
* 419,430,400% in 2032<br />
* 1,677,721,600% in 2034<br />
* 6,710,886,400% in 2036<br />
<br />
For example, if the total amount spent on running full nodes today (not counting mining) is $100 thousand per year, the estimated cost for the same level of decentralization in 2036 will be $6.7 trillion per year if validation costs stay the same. (They'll certainly go down, but algorithmic and hardware improvements probably won't eliminate an approximate 6,710,886,400% cost increase.)<br />
<br />
==== What are the dangers of the proposed hard fork? ====<br />
<br />
Under the current proposal, 75% of miners must indicate that they agree to accept blocks up to 8 MB in size.<ref name="bip101">[https://github.com/bitcoin/bips/pull/163 BIP101], Gavin Andresen, 24 June 2016</ref> After the change goes into effect, if any miner creates a block larger than 1 MB, all nodes which have not upgraded yet will reject the block.<ref>[https://bitcoin.org/en/developer-guide#consensus-rule-changes Consensus rule changes], Bitcoin.org Developer Guide</ref><br />
<br />
If all full nodes have upgraded, or very close to all nodes, there should be no practical effect. If a significant number of full nodes have not upgraded, they will continue using a different block chain than the upgraded users, with the following consequences:<br />
<br />
* Bitcoins received from before the fork can be spent twice, once on both sides of the fork. This creates a high double spend risk.<br />
* Bitcoins received after the fork are only guaranteed to be spendable on the side of the fork they were received on. This means some users will have to lose money to restore Bitcoin to a single chain.<br />
<br />
Users of hosted wallets (Coinbase, BlockChain.info, etc.) will use whatever block chain their host chooses. Users of lightweight P2P SPV wallets will use the [[Thin Client Security|longest chain they know of]], which may not be the actual longest chain if they only connect to nodes on the shorter chain. Users of non-P2P SPV wallets, like Electrum, will use whatever chain is used by the server they connect to.<br />
<br />
If a bad hard fork like this happens, it will likely cause large-scale confusion and make Bitcoin very hard to use until the situation is resolved.<br />
<br />
==== What is the deployment schedule for BIP 101? ====<br />
<br />
* The patch needs to be accepted into Bitcoin Core, Bitcoin XT, or both.<br />
* If accepted into Bitcoin Core, miners using that software will need to upgrade (this probably requires a new released version of Bitcoin Core). If accepted only into Bitcoin XT, miners will need to switch to using XT.<br />
* After 75% of miners have upgraded, 8MB blocks will become allowed at the the latest of (1) 11 January 2016 or (2) two weeks after the 75% upgrade threshold.<ref name="bip101" /><br />
* After the effective date has passed, any miner may create a block larger than 8MB. When a miner does this, upgraded full nodes will accept that block and non-upgraded full nodes will reject it, forking the network.<ref name="bip101" /> See [[#What_are_the_dangers_of_the_proposed_hard_fork.3F|hard fork dangers]] for what his might mean.<br />
<br />
==== Will miners go straight from 1 MB blocks to 8 MB blocks? ====<br />
<br />
That would be highly unlikely. Uploading an 8 MB block currently takes significantly more time than uploading a 1 MB block<ref name="rusty_dsl">[http://rusty.ozlabs.org/?p=509 Mining on a home DSL connection test results], Rusty Russell, 19 June 2015</ref>, even with the roughly 25x reduction in size available from use of Matt Corallo’s block relay network.<ref name="block_relay_net" /><br />
<br />
The longer it takes to upload a block, the higher the risk it will become a stale block—meaning the miner who created it will not receive the block subsidy or transaction fees (currently about 25 BTC per block).<br />
<br />
However, if technology like Invertible Bloom Lookup Tables (IBLTs) is deployed and found to work as expected<ref name="iblt">[https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2 O(1) block propagation], Gavin Andresen, 8 August 2014</ref>, or if mining [[#What_is_the_most_efficient_way_to_scale_Bitcoin.3F|centralizes further]], adding additional transactions may not have a significant enough cost to discourage miners from creating full blocks. In that case, blocks will be filled as soon as there are enough people wanting to make transactions paying the default relay fee<ref>[https://github.com/bitcoin/bitcoin/pull/3305 Bitcoin Core pull #3305 dropping default fees], Mike Hearn, 22 November 2013</ref> of 0.00001000 BTC/kilobyte.<br />
<br />
==== What tests have been performed related to this proposal? ====<br />
<br />
* '''20MB block processing''' (Gavin Andresen) “if we increased the maximum block size to 20 megabytes tomorrow, and every single miner decided to start creating 20MB blocks and there was a sudden increase in the number of transactions on the network to fill up those blocks… the 0.10.0 version of [Bitcoin Core] would run just fine.”<ref>[http://gavintech.blogspot.com/2015/01/twenty-megabytes-testing-results.html Twenty megabyte block testing], Gavin Andresen, 20 January 2015</ref> (ellipses in original)<br />
* '''Mining &amp; relay simulation''' (Gavin Andresen) “if blocks take 20 seconds to propagate, a network with a miner that has 30% of the hashing power will get 30.3% of the blocks.”<ref>[http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners Are bigger blocks better for bigger miners?], Gavin Andresen, 22 May 2015</ref><br />
* '''Mining on a home DSL connection''' (Rusty Russell) “Using the rough formula of 1-exp(-t/600), I would expect orphan rates of 10.5% generating 1MB blocks, and 56.6% with 8MB blocks; that’s a huge cut in expected profits.”<ref name="rusty_dsl" /><br />
* '''Mining centralization pressure''' (Pieter Wuille) “[This] does very clearly show the effects of larger blocks on centralization pressure of the system.”<ref name="wuille_centralization">[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008581.html Mining centralization pressure from non-uniform propagation speed], Pieter Wuille, 12 June 2015</ref><br />
<br />
<br />
=== Garzik Miner Block Size Voting Proposal (AKA BIP100) ===<br />
<br />
''Note, BIP 100 is the marketing name for this proposal. No BIP number<br />
has yet been publicly requested, and the number assigned is unlikely to<br />
be 100.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-May/005756.html<br />
Prenumbered BIP naming], Gregory Maxwell, 12 May 2014</ref>''<br />
<br />
Questions related to Jeff Garzik's proposal<ref name="garzik_bip">[http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf Draft BIP: decentralized economic policy], Jeff Garzik, 12 June 2015 (revised 15 June 2015)</ref> to allow miners to vote on raising and lowering the maximum block size.<br />
<br />
==== What does this proposal do? ====<br />
<br />
# It creates a one-time hard fork that does not automatically change the maximum block size.<br />
<br />
# It allows miners to vote to increase or decrease the maximum block size within the range of 1MB to 32MB. These changes are neither hard forks nor soft forks, but simply rules that all nodes should know about after the initial hard fork.<br />
<br />
==== Does it reduce the risk of a hard fork? ====<br />
<br />
Hard forks are most dangerous when they're done without strong<br />
consensus.<ref name="garzik_bip" /><ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008779.html Consensus changes are not about making a change to the software],<br />
Pieter Wuille, 18 June 2015</ref><br />
<br />
If Garzik's proposal gains strong consensus, it will be as safe as possible<br />
for a hard fork and it will allow increasing the block size up to 32 MB<br />
without any additional risk of a fork.<br />
<br />
==== Why is it limited to 32 megabytes? ====<br />
<br />
According to the draft BIP, "the 32 MB hard fork is largely coincidental -- a whole network upgrade at 32 MB was likely needed anyway."<br />
<br />
=== Lightning Network ===<br />
<br />
Questions related to using the proposed [http://lightning.network/ Lightning network] as a way to scale the number of users Bitcoin can support.<br />
<br />
==== How does transaction security differ from that of Bitcoin? ====<br />
<br />
Transactions on the proposed Lightning network use Bitcoin transactions exclusively to transfer bitcoins<ref name="russell_lightning1">[http://rusty.ozlabs.org/?p=450 Lightning Networks: Part I], Rusty Russell, 30 March 2015</ref>, and so the same security as regular Bitcoin transactions is provided when both a Lightning hub and client are cooperating.<br />
<br />
When a Lightning hub or client refuses to cooperate with the other (maybe because they accidentally went offline), the other party can still receive their full 100% bitcoin balance by closing the payment channel—but they must first wait for a defined amount of time mutually chosen by both the hub and client.<ref>[http://rusty.ozlabs.org/?p=462 Lightning Networks: Part II], Rusty Russell, 1 April 2015</ref><br />
<br />
If one party waits too long to close the payment channel, the other party may be able to steal bitcoins. However, it is possible to delegate the task of closing the channel in an emergency to an unlimited number of hubs around the Internet, so closing the channel on time should be easy.<ref name="russell_lightning4">[http://rusty.ozlabs.org/?p=477 Lightning Networks: Part IV], Rusty Russell, 8 April 2015</ref><br />
<br />
In summary, provided that payment channels are closed on time, the worst that can happen to users is that they may have to wait a few weeks for a channel to fully close before spending the bitcoins they received from it. Their security is otherwise the same as with regular Bitcoin.<br />
<br />
For Lightning hubs, security is slightly worse in the sense that they need to keep a potentially-large amount of funds in a hot wallet<ref name="lightning_paper">[http://lightning.network/lightning-network-paper-DRAFT-0.5.pdf Lightning Network (Draft 0.5)], Section 6.3: Coin Theft via Hacking, Joseph Poon and Thaddeus Dryja</ref>, so they can’t take advantage of the anti-hacking protection offered by cold wallets. Otherwise, Lightning hubs have the same security as clients.<br />
<br />
==== When will Lightning be ready for use? ====<br />
<br />
Lightning requires a basic test implementation (work underway<ref>[https://lists.blockstream.com/pipermail/lightning-dev/2015-June/000018.html Lightning first steps], Rusty Russell, 13 June 2015</ref>), several soft-fork changes to the Bitcoin protocol (work underway<ref>[https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65: CheckLockTimeVerify], Peter Todd, 1 October 2014</ref><ref>[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68: Consensus-enforced transaction replacement], Mark Friedenbach, 28 May 2015</ref>, and wallets need to be updated to support the Lightning network protocol.<ref name="russell_lightning4" /><br />
<br />
Dr. Adam Back has said, "I expect we can get something running inside a year."<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009242.html Reply to Andresen regarding Lightning], Dr. Adam Back, 28 June 2015</ref><br />
<br />
==== Doesn’t Lightning require bigger blocks anyway? ====<br />
<br />
Lightning is block-size neutral. It requires one on-chain transaction to open a channel between a hub and a client, and one on-chain transaction to close a channel.<ref name="russell_lightning1" /> In between it can support an unlimited number of transactions between anyone on the Lightning network.<ref name="lightning_paper" /><br />
<br />
Using the numbers from the Lightning presentation<ref name="lightning_slides">[http://lightning.network/lightning-network.pdf Lightning presentation], Joseph Poon, 23 February 2015</ref>, if people open and close a plausible two channels a year, Lightning can support about 52 million users with the current one-megabyte limit—and each user can make an unlimited number of transactions. Currently, assuming people make an average of only two Bitcoin transactions a day, basic Bitcoin can support only 288,000 users.<br />
<br />
Under these assumptions, Lightning is 180 times (17,900%) more efficient than basic Bitcoin.<br />
<br />
Presumably, if around 30 million people are using Bitcoin via Lightning so that capacity is called into question, it will not be difficult to find consensus to double the block size to two megabytes and bring user capacity up to 105 million. The same goes for later increases to 200 million (4MB), 400 million (8MB), 800 million (16MB), 1.6 billion (32 MB), 3.2 billion (64MB), and all 7 billion living humans (133MB). In each case, all Lightning network participants get unlimited transactions to the other participants.<br />
<br />
For basic Bitcoin to scale to just 2 transactions a day for 7 billion people would require 24-gigabyte blocks.<ref name="lightning_slides" /><br />
<br />
=== Sidechains ===<br />
<br />
==== Real quick, what are sidechains? ====<br />
<br />
Block chains that are separate from Bitcoin’s block chain, but which allow you to receive and spend bitcoins using a two-way peg (2WP).<ref name="sidechains_paper">[https://www.blockstream.com/sidechains.pdf Sidechains paper], Adam Back et al., 22 October 2014</ref> (Although a sidechain can never be more secure than the Bitcoin block chain.<ref>[https://www.reddit.com/r/Bitcoin/comments/39r85g/sidechain_hate/cs5spbg Security limitations of pegged chains], Gregory Maxwell, 14 June 2015</ref>)<br />
<br />
==== Are sidechains a scaling option? ====<br />
<br />
No. Sidechains have the same fundamental scaling problems as Bitcoin does. Moving some transactions to sidechains simply moves some problems elsewhere on the network—the total difficulty of the problem remains the same.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008617.html Sidechains not a direct means for solving any of the scaling problems Bitcoin has], Pieter Wuille, 13 June 2015</ref><br />
<br />
==== But couldn’t I create a sidechain that had 100 GB blocks? ====<br />
<br />
Certainly, sidechain code is open source<ref>[https://github.com/ElementsProject/elements Elements Project]</ref>—so you can create your own sidechain. But you’d still have the difficulty of finding people who are willing to validate 100 GB blocks with their own full nodes.<br />
<br />
==== Do sidechains require a hard fork? ====<br />
<br />
No. Federated sidechains, such as have already been implemented<ref>[https://github.com/ElementsProject/elements/tree/alpha Elements Alpha]</ref>, don’t require any changes to the Bitcoin consensus rules. Merged-mined sidechains, which have not been implemented yet, do require a backwards-compatible soft fork in order to transfer funds between Bitcoin and the sidechain.<ref name="sidechains_paper" /><br />
<br />
== References ==<br />
<references /></div>Amincdhttps://en.bitcoin.it/w/index.php?title=Scalability_FAQ&diff=60392Scalability FAQ2016-02-14T15:55:51Z<p>Amincd: /* What happens if blocks aren't big enough to include all pending transactions? */</p>
<hr />
<div>Answers to commonly-asked questions and concerns about scaling Bitcoin, including “level 1” solutions such as increasing the block size and “level 2” solutions such as the proposed Lightning network.<br />
<br />
== Background ==<br />
<br />
Questions about how Bitcoin currently works (related to scaling) as well as questions about the technical terminology related to the scaling discussion.<br />
<br />
=== What is the short history of the block size limit? ===<br />
<br />
''Note: the software now called Bitcoin Core was previously simply called “Bitcoin”.<ref>[https://bitcoin.org/en/release/v0.9.0#rebranding-to-bitcoin-core Bitcoin Core 0.9.0 release notes], Bitcoin.org, 19 March 2014</ref> To avoid confusion with the Bitcoin system, we’ll use the Bitcoin Core name.''<br />
<br />
Bitcoin Core was initially released without an explicit block size limit. However, the code did limit network messages to a maximum of 32 MiB, setting an effective upper bound on block size.<ref>[https://bitcointalk.org/index.php?topic=68121 Earliest known Bitcoin code], <code>src/main.h:17</code></ref><br />
<br />
Around 15 July 2010, Satoshi Nakamoto changed Bitcoin Core’s mining code so that it wouldn’t create any blocks larger than 990,000 bytes.<ref>[https://github.com/bitcoin/bitcoin/commit/a30b56ebe76ffff9f9cc8a6667186179413c6349 Bitcoin Core commit a30b56e], Satoshi Nakamoto, 15 July 2010</ref><br />
<br />
Two months later on 7 September 2010, Nakamoto changed Bitcoin Core’s consensus rules to reject blocks larger than 1,000,000 bytes (1 megabyte) if their block height was higher than 79,400.<ref>[https://github.com/bitcoin/bitcoin/commit/8c9479c6bbbc38b897dc97de9d04e4d5a5a36730 Bitcoin Core commit 8c9479c], Satoshi Nakamoto, 7 September 2010</ref> (Block 79,400 was later produced on 12 September 2010.<ref>[https://www.biteasy.com/blockchain/blocks/000000000021d821ec06be7173f413690bc5c4bc648dfa70b3b6763236f055b7 Block height 79400], dated 12 September 2010</ref>)<br />
<br />
Neither the July nor the September commit message explains the reason for the limit, although the careful attempt to prevent a fork may indicate Nakamoto didn’t consider it an emergency.<br />
<br />
Nakamoto’s subsequent statements supported raising the block size at a later time<ref>[https://bitcointalk.org/index.php?topic=1347.msg15139#msg15139 Increasing the block size when needed], Satoshi Nakamoto, 3 October 2010</ref>, but he never publicly specified a date or set of conditions for the raise.<br />
<br />
Statements by Nakamoto in the summer of 2010 indicate he believed Bitcoin could scale to block sizes far larger 1 megabyte. For example, on 5 August 2010, he wrote that "[W]hatever size micropayments you need will eventually be practical. I think in 5 or 10 years, the bandwidth and storage will seem trivial" and "[microtransactions on the blockchain] can become more practical ... if I implement client-only mode and the number of network nodes consolidates into a smaller number of professional server farms" <ref>[https://bitcointalk.org/index.php?topic=532.msg6306#msg6306 the number of network nodes consolidates into a smaller number of professional server farms]</ref>. <br />
<br />
These statements suggest that the intended purpose of the 1 megabyte limit was not to keep bandwidth and storage requirements for running a Bitcoin node low enough to be practical for personal computers and consumer-grade internet connections, and that the limit would be lifted to accommodate greater demand for transactional capacity.<br />
<br />
=== What is this Transactions Per Second (TPS) limit? ===<br />
<br />
The current block size limit is 1,000,000 bytes (1 megabyte)<ref>[https://github.com/bitcoin/bitcoin/blob/41076aad0cbdfa4c4cf376e345114a5c29086f81/src/consensus/consensus.h#L10 <code>MAX_BLOCK_SIZE</code>], retrieved 2 July 2015</ref>, although a small amount of that space (such as the block header) is not available to store transactions.<ref>[https://bitcoin.org/en/developer-reference#serialized-blocks Block serialization description], Bitcoin.org Developer Reference</ref><br />
<br />
Bitcoin transactions vary in size depending on multiple factors, such as whether they’re spending single-signature inputs or a multiple signature inputs, and how many inputs and outputs they have.<br />
<br />
The simple way to calculate the number of Transactions Per Second (TPS) Bitcoin can handle is to divide the block size limit by the expected average size of transactions, divided by the average number of seconds between blocks (600). For example, if you assume average transactions are 250 bytes,<br />
<br />
<pre>6.6 TPS = 1,000,000 / 250 / 600</pre><br />
<br />
There seems to be general agreement that Bitcoin in 2015 can handle about 3 TPS with the current average size of transactions.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/007986.html Max TPS based on current average transaction size], Mike Hearn, 8 May 2015</ref><ref name="maxwell_not_proposing">[https://www.reddit.com/r/Bitcoin/comments/39yaod/bitcoinorg_position_on_hard_forks/cs7qz5c "No one proposing 3 TPS forever"], Gregory Maxwell, 15 June 2015</ref><br />
<br />
Both old estimates<ref>[[Scalability]], Bitcoin Wiki, retrieved 7 July<br />
2015</ref> and new estimates<ref name="garzik_bip" /> place the<br />
theoretical maximum at 7 TPS with current Bitcoin consensus rules<br />
(including the 1MB block size limit).<br />
<br />
=== What do devs mean by the scaling expressions O(1), O(n), O(n<sup>2</sup>), etc…? ===<br />
<br />
[https://en.wikipedia.org/wiki/Big_O_notation Big O notation] is a shorthand used by computer scientists to describe how well a system scales. Such descriptions are rough approximations meant to help predict potential problems and evaluate potential solutions; they are not usually expected to fully capture all variables.<br />
<br />
* '''O(1)''' means a system has roughly the same properties no matter how big it gets.<br />
* '''O(n)''' means that a system scales linearly: doubling the number of things (users, transactions, etc.) doubles the amount of work.<br />
* '''O(n<sup>2</sup>)''' means that a system scales quadratically : doubling (2x) the number of things quadruples (4x) the amount of work. Often written O(n^2) is places without convenient superscripts.<br />
* Additional examples may be found in the [https://en.wikipedia.org/wiki/Big_O_notation#Orders_of_common_functions Wikipedia article]<br />
<br />
The following subsections show cases where big O notation has been applied to the scaling Bitcoin transaction volume.<br />
<br />
==== O(1) block propagation ====<br />
<br />
Bitcoin Core currently relays unconfirmed transactions and then later relays blocks containing many of the same transactions. This redundant relay can be eliminated to allow miners to propagate large blocks very quickly to active network nodes, and would also significantly reduce miner need for peak bandwidth. Currently most miners use a network<ref name="block_relay_net">[http://bitcoinrelaynetwork.org/ Matt Corallo's block relay network]</ref> that is about 25x more efficient than stock Bitcoin Core<ref>[https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2#i-know-that-you-know IBLT design document], Gavin Andresen, 11 August 2014</ref> and almost equally as effective as O(1) block propagation for current block sizes.<br />
<br />
=== What’s the difference between on-chain and off-chain transactions? ===<br />
<br />
On-chain Bitcoin transactions are those that appear in the Bitcoin block chain. Off-chain transactions are those that transfer ownership of bitcoins without putting a transaction on the block chain.<br />
<br />
Common and proposed off-chain transactions include:<br />
<br />
* '''Exchange transactions:''' when you buy or sell bitcoins, the exchange tracks ownership in a database without putting data in the block chain. Only when you deposit or withdraw bitcoins does the transaction appear on the block chain.<br />
* '''Web wallet internal payments:''' many web wallets allow users of the service to pay other users of the same service using off-chain payments. For example, when one Coinbase user pays another Coinbase user.<br />
* '''Tipping services:''' most tipping services today, such as ChangeTip, use off-chain transactions for everything except deposits and withdrawals.<ref>[https://www.changetip.com/fees ChangeTip fees], retrieved 3 July 2015</ref><br />
* '''Payment channels:''' channels are started using one on-chain transaction and ended using a second on-chain transaction.<ref>[https://bitcoin.org/en/developer-guide#micropayment-channel Micropayment channels], Bitcoin.org Developer Guide</ref> In between can be an essentially unlimited number of off-chain transactions as small as a single satoshi (1/100,000,000th of a bitcoin). Payment channels include those that [https://bitcoinj.github.io/working-with-micropayments exist today] as well as proposed hub-and-spoke channels and the more advanced [http://lightning.network/ Lightning network].<br />
<br />
Approximately 90% to 99% of all bitcoin-denominated payments today are made off-chain.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008844.html Pure off-chain is a weak form of layer 2], Dr. Adam Back, 19 June 2015</ref><br />
<br />
=== What is a fee market? ===<br />
<br />
When you create a Bitcoin transaction, you have the option to pay a [[transaction fee]]. If your software is flexible, you can pay anything from zero fees (a free transaction) to 100% of the value of the transaction (spend-to-fees). This fee is comparable to a tip. The higher it is, the bigger the incentive of the miners to incorporate your transaction into the next block.<br />
<br />
When miners assemble a block, they are free to include whatever transactions they wish. They usually include as many as possible up to the maximum block size and then prioritize the transactions that pay the most fees per kilobyte of data.<ref name="fee_pri">[https://bitcointalk.org/index.php?topic=95837.0 Fee prioritization patch], Gavin Andresen, 26 July 2012</ref> This confirms higher-fee transactions before lower-fee transactions. If blocks become full on a regular basis, users who pay a fee that's too small will have to wait a longer and longer time for their transactions to confirm. At this point, a demand-driven fee market may arise where transactions that pay higher fees get confirmed significantly faster than transactions that pay low fees.<ref name="todd_coinwallet">[https://gist.github.com/petertodd/8e87c782bdf342ef18fb Comments on the CoinWallet.eu tx-flood stress-test], Peter Todd, 22 June 2015</ref><ref name="garzik_bip" /><br />
<br />
In a competitive market, prices are driven by supply and demand and the emerging equilibrium price asymptotically approaches marginal costs over time. However, the current version of Bitcoin limits the supply to 1 MB per block, only allowing demand to adjust. To establish a free market, one would need to come up with a mechanism that allows the number of included transactions per block to adjust dynamically as well. The design of such a mechanism, however, is not trivial. Simply allowing individual miners to include as many transactions as they want is problematic due to the externalities<ref name="exernality">[https://en.wikipedia.org/wiki/Externality Definition of externality], Wikipedia, 26 January 2016</ref> of including additional blocks and explained further in section [[#Should miners be allowed to decide the block size?|'should miners be allowed to decide the block size?']] .<br />
<br />
=== What is the most efficient way to scale Bitcoin? ===<br />
<br />
Remove its decentralization properties, specifically decentralized mining and decentralized full nodes. Mining wastes enormous amounts of electricity to provide a decentralized ledger and full nodes waste an enormous amount of bandwidth and CPU time keeping miners honest.<br />
<br />
If users instead decided to hand authority over to someone they trusted, mining and keeping miners honest wouldn’t be needed. This is how Visa, MasterCard, PayPal, and the rest of the centralized payment systems works—users trust them, and they have no special difficulty scaling to [[scalability|millions of transactions an hour]]. It’s very efficient; it isn’t decentralized.<br />
<br />
=== What is a hard fork, and how does it differ from other types of forks? ===<br />
<br />
The word fork is badly overloaded in Bitcoin development.<br />
<br />
* '''[[hardfork|Hard fork]]:''' a change to the system which is not backwards compatible. Everyone needs to upgrade or things can go wrong.<br />
* '''[[softfork|Soft fork]]:''' a change to the system which is backwards compatible as long as a majority of miners enforce it. Full nodes that don’t upgrade have their security reduced.<br />
* '''Chain fork:''' when there are two are more blocks at the same height on a block chain. This typically happens a few times a week by accident, but it can also indicate more severe problems.<br />
* '''[https://en.wikipedia.org/wiki/Fork_%28software_development%29 Software fork]:''' using the code from an open source project to create a different project.<br />
* '''[https://help.github.com/articles/fork-a-repo/ Git/GitHub fork]:''' a way for developers to write and test new features before contributing them to a project.<br />
<br />
(There are other types of software-related forks, but they don’t tend to cause as much confusion.)<br />
<br />
=== What are the block size soft limits? ===<br />
<br />
Bitcoin Core has historically come pre-configured to limit blocks it mines to certain sizes.<ref name="fee_pri" /> These “limits” aren’t restrictions placed on miners by other miners or nodes, but rather configuration options that help miners produce reasonably-sized blocks.<br />
<br />
Miners can change their soft limit size (up to 1 MB) using <code>-blockmaxsize=&lt;size&gt;</code><br />
<br />
Default soft limits at various times:<br />
<br />
* '''July 2012:''' <code>-blockmaxsize</code> option created and set to default 250 KB soft limit<ref>[https://github.com/bitcoin/bitcoin/commit/c555400ca134991e39d5e3a565fcd2215abe56f6 Bitcoin Core commit c555400], Gavin Andresen, 12 July 2012</ref><br />
* '''November 2013:''' Raised to 750KB<ref>[https://github.com/bitcoin/bitcoin/commit/ad898b40aaf06c1cc7ac12e953805720fc9217c0 Bitcoin Core commit ad898b40], Gavin Andresen, 27 November 2013</ref><br />
* '''June 2015:''' Raise to 1 MB suggested<ref>[https://github.com/bitcoin/bitcoin/pull/6231 Bitcoin Core pull #6231], Chris Wheeler, 4 June 2015</ref><br />
<br />
== General Block Size Increase Theory ==<br />
<br />
Questions about increasing the block size in general, not related to any<br />
specific proposal.<br />
<br />
==== Why are some people in favor of keeping the block size at 1 MB forever? ====<br />
<br />
It is commonly claimed<ref name="garzik_bip" /><ref>[https://epicenterbitcoin.com/podcast/082/ Epicenter Bitcoin podcast #82], Mike Hearn (interviewed), 8 June 2015</ref> that there are people opposed to ever raising the maximum block size limit, but no Bitcoin developers have suggested keeping the maximum block size at one megabyte forever.<ref name="maxwell_not_proposing" /><br />
<br />
All developers support raising the maximum size at some point<ref>[https://www.reddit.com/r/Bitcoin/comments/39kqzs/how_about_a_softfork_optin_blocksize_increase/cs5hj8l Nothing magic about 1MB], Dr. Adam Back, 13 June 2015</ref><ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008328.html Regarding size-independent new block propagation], Pieter Wuille, 28 May 2015</ref>—they just disagree about whether now is the correct time.<br />
<br />
==== Should miners be allowed to decide the block size? ====<br />
<br />
A block may include as little as a single transaction, so miners can always restrict block size. Letting miners choose the maximum block size is more problematic for several reasons:<br />
<br />
# '''Miners profit, others pay the cost:''' bigger blocks earn miners more fees, but miners don’t need to store those blocks for more than a few days.<ref>[https://github.com/bitcoin/bitcoin/pull/5863 Bitcoin Core pull #5863 adding pruning functionality], Suhas Daftuar et al., 6 March 2015</ref> Other users who want full validation security, or who provide services to lightweight wallets, pay the costs of downloading and storing those larger blocks.<br />
# '''Bigger miners can afford more bandwidth:''' each miner needs to download every transaction that will be included in block,<ref name="maxwell_correcting_assumptions" /> which means that they all need to pay for high-speed connections. However, a miner with 8.3% of total hash rate can take that cost out of the about 300 BTC they make a day, while a miner with only 0.7% of total hash rate has to take that cost out of only 25 BTC a day. This means bigger miners may logically choose to make bigger blocks even though it may further centralize mining.<br />
# '''Centralized hardware production:''' only a few companies in the world produce efficient mining equipment, and many of them have chosen to stop selling to the public.<ref>[http://blogs.wsj.com/venturecapital/2014/09/05/for-kncminer-time-to-forget-selling-bitcoin-machines-to-at-home-miners/ KnCMiner to stop selling to home miners], Wall Street Journal, Yuliya Chernova, 5 September 2014</ref> This prevents ordinary Bitcoin users from participating in the process even if they were willing to pay for mining equipment.<br />
# '''Voting by hash rate favors larger miners:''' voting based on hash rate allows the current hash rate majority (or super-majority) to enforce conditions on the minority. This is similar to a lobby of large businesses being able to get laws passed that may hurt smaller businesses.<ref>[https://www.reddit.com/r/Bitcoin/comments/39kzyt/draft_bip_100_soft_fork_block_size_increase/cs5gvak Miners choosing the block size limit is ill-advised], Meni Rosenfeld, 13 June 2015</ref><br />
# '''Miners may not care about users:''' this was demonstrated during the [[July 2015 Forks]] where even after miners lost over $50,000 USD in income from mining invalid chains, and even after they were told that long forks harm users, they continued to mine improperly.<ref>[https://bitcointalk.org/index.php?topic=700411.msg11790734#msg11790734 Intention to continue SPV mining], Wang Chun, 4 July 2015</ref><br />
<br />
However, there are also possible justifications for letting miners choose the block size:<br />
<br />
# '''Authenticated participants:''' miners are active participants in Bitcoin, and they can prove it by adding data to the blocks they create.<ref>[https://bitcoin.org/en/developer-reference#term-coinbase-field Coinbase field], Bitcoin.org Developer Reference</ref> It is much harder to prove people on Reddit, BitcoinTalk, and elsewhere are real people with an active stake in Bitcoin.<br />
# '''Bigger blocks may cost miners:''' small miners and poorly-connected miners are at a disadvantage if larger blocks are produced<ref name="wuille_centralization" />, and even large and well-connected miners may find that large blocks reduce their profit percentage if the cost of bandwidth rises too high or their stale rate increases.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008355.html F2Pool block size concerns], Chun Wang, 29 May 2015</ref><br />
<br />
==== How could a block size increase affect user security? ====<br />
<br />
Bitcoin’s security is highly dependent on the number of active users who protect their bitcoins with a full node like Bitcoin Core. The more active users of full nodes, the harder it is for miners to trick users into accepting fake bitcoins or other frauds.<ref>[https://medium.com/@lopp/bitcoin-nodes-how-many-is-enough-9b8e8f6fd2cf Bitcoin nodes: how many is enough?], Jameson Lopp, 7 June 2015</ref><br />
<br />
Full nodes need to download and verify every block, and most nodes also store blocks plus relay transactions, full blocks, and filtered blocks to other users on the network. The bigger blocks become, the more difficult it becomes to do all this, so it is expected that bigger blocks will both reduce the number of users who currently run full nodes and suppress the number of users who decide to start running a full node later.<ref>[https://www.reddit.com/r/Bitcoin/comments/3bae2d/amir_taaki_on_raising_the_block_size_a_lot_of/cslcgmw Block size increases-only will create problems], Dr. Adam Back, 28 June 2015</ref><br />
<br />
In addition, full blocks may increase mining centralization<ref name="wuille_centralization" /> at a time when mining is already so centralized that it makes it easy to reverse transactions which have been confirmed multiple times.<ref>[http://bitcoin.stackexchange.com/questions/32562/when-to-worry-about-1-confirmation-payments/32564#32564 When to worry about one-confirmation payments], David A. Harding, 17 November 2014</ref><br />
<br />
==== How could larger blocks affect proof-of-work (POW) security? ====<br />
<br />
Proof of work security is dependent on how much money miners spend on mining equipment. However, to effectively mine blocks, miners also need to spend money on bandwidth to receive new transactions and blocks created by other miners; CPUs to validate received transactions and blocks; and bandwidth to upload new blocks. These additional costs don’t directly contribute to POW security.<ref name="maxwell_correcting_assumptions">[https://www.reddit.com/r/Bitcoin/comments/39tgno/letting_miners_vote_on_the_maximum_block_size_is/cs6rek5 Correcting wrong assumptions about mining], Gregory Maxwell, 15 June 2015</ref><br />
<br />
As block sizes increase, the amount of bandwidth and CPU required also increases. If block sizes increase faster than the costs of bandwidth and CPU decrease, miners will have less money for POW security relative to the gross income they earn.<br />
<br />
In addition, larger blocks have a higher risk of becoming stale (orphaned)<ref name="rusty_dsl" />, which directly correlates to lost POW security. For example, if the network average stale rate is 10%, then 10% of POW performed isn't protecting transactions on the block chain.<br />
<br />
Conversely, larger blocks that result in a lower per transaction fee can increase the demand for on-chain transactions, and result in total transaction fees earned by miners increasing despite a lower average transaction fee. This would increase network security by increasing the revenue that supports Proof of Work generation. <br />
<br />
Without an increase in the block size from 1 megabyte, Bitcoin needs $1.50 worth of BTC paid in fees per transaction once block subsidies disappear to maintain current mining revenue and economic expenditure on network security. The required fee per transaction for maintaining current economic expenditure levels once the subsidy disappears decreases as the block size, and with it the maximum on-chain transaction throughput, increases. <br />
<br />
As a result of the sensitivity of demand to price increases, growth in the Bitcoin economy, and thus growth in the fees paid to secure the Bitcoin network, could be stunted if the block size is not allowed to increase sufficiently.<br />
<br />
=== What happens if blocks aren't big enough to include all pending transactions? ===<br />
<br />
This is already the case more often than not<ref>[http://statoshi.info/dashboard/db/transactions?from=1433297061121&to=1435889061123 Statoshi.info mempool queue June to July 2015]</ref>, so we know that miners will simply queue transactions. The transactions eligible for block inclusion that pay the highest fee per kilobyte will be confirmed earlier than transactions that pay comparatively lower fees.<ref name="fee_pri" /><br />
<br />
Basic economic theory tells us that increases in price reduce demand, ceteris paribus. Assuming that larger blocks would not cause a loss of demand for on-chain transaction processing due to a perceived loss of the network's decentralization and censorship resistance, a block size that is too small to include all pending transactions will result in less demand for on-chain transaction processing.<br />
<br />
What happens from there is debated:<br />
<br />
* BitcoinJ lead developer Mike Hearn believes there would be “crashing nodes, a swelling transaction backlog, a sudden spike in double spending, [and] skyrocketing fees.”<ref>[https://medium.com/@octskyward/crash-landing-f5cc19908e32 Crash Landing], Mike Hearn, 7 May 2015</ref><br />
* Bitcoin Foundation chief scientist Gavin Andresen believes that the “average transaction fee paid will rise, people or applications unwilling or unable to pay the rising fees will stop submitting transactions, [and] people and businesses will shelve plans to use Bitcoin, stunting growth and adoption.” <ref>[https://github.com/bitcoin/bitcoin/pull/6341 Bitcoin Core pull #6341], Gavin Andresen, 26 June 2015</ref><br />
* Bitcoin Core developer Pieter Wuille replies to Andresen’s comment above: “Is it fair to summarize this as ‘Some use cases won’t fit any more, people will decide to no longer use the blockchain for these purposes, and the fees will adapt.’? I think that is already happening […] I don’t think we should be afraid of this change or try to stop it.” <ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009098.html The need for larger blocks], Pieter Wuille, 26 June 2015</ref><br />
* Bitcoin Core developer Jeff Garzik writes, "as blocks get full and the bidding war ensues, the bitcoin user experience rapidly degrades to poor. In part due to bitcoin wallet software’s relative immaturity, and in part due to bitcoin’s settlement based design, the end user experience of their transaction competing for block size results in erratic, and unpredictably extended validation times."<ref name="garzik_bip" /><br />
<br />
== Specific Scaling Proposals ==<br />
<br />
=== Andresen-Hearn Block Size Increase Proposals ===<br />
<br />
Questions about the series of related proposals by Gavin Andresen and Mike Hearn to use a hard fork to raise the maximum block size, thereby allowing miners to include more on-chain transactions. As of July 2015, the current focus is [https://github.com/bitcoin/bips/pull/163 BIP101].<br />
<br />
==== What is the major advantage of this proposal? ====<br />
<br />
''Bitcoin can support many more users.'' Assuming earliest possible adoption, 250 bytes per on-chain transaction, 144 blocks per day, and 2 transaction a day per user, Bitcoin can support about,<br />
<br />
* 288,000 users in 2015<br />
* 2,304,000 users in 2016 (800% increase)<br />
* 4,608,000 in 2018 (1,600%)<br />
* 9,216,000 in 2020 (3,200%)<br />
* 18,432,000 in 2022 (6,400%)<br />
* 36,864,000 in 2024 (12,800%)<br />
* 73,728,000 in 2026 (25,600%)<br />
* 147,456,000 in 2028 (51,200%)<br />
* 294,912,000 in 2030 (102,400%)<br />
* 589,824,000 in 2032 (204,800%)<br />
* 1,179,648,000 in 2034 (409,600%<br />
* 2,359,296,000 in 2036 (819,200%)<br />
<br />
==== What is the major disadvantage of this proposal? ====<br />
<br />
''The total cost of remaining decentralized will be high.'' Assuming earliest possible adoption and that the ratio of total users to full node operators remains the same as today, the total estimated amount of work necessary to maintain the decentralized system under the [[#O.28n2.29_network_total_validation_resource_requirements|O(<sup>2</sup>) scaling model]] will be,<br />
<br />
* 100% of today’s work in 2015<br />
* 6,400% in 2016<br />
* 25,600% in 2018<br />
* 102,400% in 2020<br />
* 409,600% in 2022<br />
* 1,638,400% in 2024<br />
* 6,553,600% in 2026<br />
* 26,214,400% in 2028<br />
* 104,857,600% in 2030<br />
* 419,430,400% in 2032<br />
* 1,677,721,600% in 2034<br />
* 6,710,886,400% in 2036<br />
<br />
For example, if the total amount spent on running full nodes today (not counting mining) is $100 thousand per year, the estimated cost for the same level of decentralization in 2036 will be $6.7 trillion per year if validation costs stay the same. (They'll certainly go down, but algorithmic and hardware improvements probably won't eliminate an approximate 6,710,886,400% cost increase.)<br />
<br />
==== What are the dangers of the proposed hard fork? ====<br />
<br />
Under the current proposal, 75% of miners must indicate that they agree to accept blocks up to 8 MB in size.<ref name="bip101">[https://github.com/bitcoin/bips/pull/163 BIP101], Gavin Andresen, 24 June 2016</ref> After the change goes into effect, if any miner creates a block larger than 1 MB, all nodes which have not upgraded yet will reject the block.<ref>[https://bitcoin.org/en/developer-guide#consensus-rule-changes Consensus rule changes], Bitcoin.org Developer Guide</ref><br />
<br />
If all full nodes have upgraded, or very close to all nodes, there should be no practical effect. If a significant number of full nodes have not upgraded, they will continue using a different block chain than the upgraded users, with the following consequences:<br />
<br />
* Bitcoins received from before the fork can be spent twice, once on both sides of the fork. This creates a high double spend risk.<br />
* Bitcoins received after the fork are only guaranteed to be spendable on the side of the fork they were received on. This means some users will have to lose money to restore Bitcoin to a single chain.<br />
<br />
Users of hosted wallets (Coinbase, BlockChain.info, etc.) will use whatever block chain their host chooses. Users of lightweight P2P SPV wallets will use the [[Thin Client Security|longest chain they know of]], which may not be the actual longest chain if they only connect to nodes on the shorter chain. Users of non-P2P SPV wallets, like Electrum, will use whatever chain is used by the server they connect to.<br />
<br />
If a bad hard fork like this happens, it will likely cause large-scale confusion and make Bitcoin very hard to use until the situation is resolved.<br />
<br />
==== What is the deployment schedule for BIP 101? ====<br />
<br />
* The patch needs to be accepted into Bitcoin Core, Bitcoin XT, or both.<br />
* If accepted into Bitcoin Core, miners using that software will need to upgrade (this probably requires a new released version of Bitcoin Core). If accepted only into Bitcoin XT, miners will need to switch to using XT.<br />
* After 75% of miners have upgraded, 8MB blocks will become allowed at the the latest of (1) 11 January 2016 or (2) two weeks after the 75% upgrade threshold.<ref name="bip101" /><br />
* After the effective date has passed, any miner may create a block larger than 8MB. When a miner does this, upgraded full nodes will accept that block and non-upgraded full nodes will reject it, forking the network.<ref name="bip101" /> See [[#What_are_the_dangers_of_the_proposed_hard_fork.3F|hard fork dangers]] for what his might mean.<br />
<br />
==== Will miners go straight from 1 MB blocks to 8 MB blocks? ====<br />
<br />
That would be highly unlikely. Uploading an 8 MB block currently takes significantly more time than uploading a 1 MB block<ref name="rusty_dsl">[http://rusty.ozlabs.org/?p=509 Mining on a home DSL connection test results], Rusty Russell, 19 June 2015</ref>, even with the roughly 25x reduction in size available from use of Matt Corallo’s block relay network.<ref name="block_relay_net" /><br />
<br />
The longer it takes to upload a block, the higher the risk it will become a stale block—meaning the miner who created it will not receive the block subsidy or transaction fees (currently about 25 BTC per block).<br />
<br />
However, if technology like Invertible Bloom Lookup Tables (IBLTs) is deployed and found to work as expected<ref name="iblt">[https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2 O(1) block propagation], Gavin Andresen, 8 August 2014</ref>, or if mining [[#What_is_the_most_efficient_way_to_scale_Bitcoin.3F|centralizes further]], adding additional transactions may not have a significant enough cost to discourage miners from creating full blocks. In that case, blocks will be filled as soon as there are enough people wanting to make transactions paying the default relay fee<ref>[https://github.com/bitcoin/bitcoin/pull/3305 Bitcoin Core pull #3305 dropping default fees], Mike Hearn, 22 November 2013</ref> of 0.00001000 BTC/kilobyte.<br />
<br />
==== What tests have been performed related to this proposal? ====<br />
<br />
* '''20MB block processing''' (Gavin Andresen) “if we increased the maximum block size to 20 megabytes tomorrow, and every single miner decided to start creating 20MB blocks and there was a sudden increase in the number of transactions on the network to fill up those blocks… the 0.10.0 version of [Bitcoin Core] would run just fine.”<ref>[http://gavintech.blogspot.com/2015/01/twenty-megabytes-testing-results.html Twenty megabyte block testing], Gavin Andresen, 20 January 2015</ref> (ellipses in original)<br />
* '''Mining &amp; relay simulation''' (Gavin Andresen) “if blocks take 20 seconds to propagate, a network with a miner that has 30% of the hashing power will get 30.3% of the blocks.”<ref>[http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners Are bigger blocks better for bigger miners?], Gavin Andresen, 22 May 2015</ref><br />
* '''Mining on a home DSL connection''' (Rusty Russell) “Using the rough formula of 1-exp(-t/600), I would expect orphan rates of 10.5% generating 1MB blocks, and 56.6% with 8MB blocks; that’s a huge cut in expected profits.”<ref name="rusty_dsl" /><br />
* '''Mining centralization pressure''' (Pieter Wuille) “[This] does very clearly show the effects of larger blocks on centralization pressure of the system.”<ref name="wuille_centralization">[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008581.html Mining centralization pressure from non-uniform propagation speed], Pieter Wuille, 12 June 2015</ref><br />
<br />
<br />
=== Garzik Miner Block Size Voting Proposal (AKA BIP100) ===<br />
<br />
''Note, BIP 100 is the marketing name for this proposal. No BIP number<br />
has yet been publicly requested, and the number assigned is unlikely to<br />
be 100.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-May/005756.html<br />
Prenumbered BIP naming], Gregory Maxwell, 12 May 2014</ref>''<br />
<br />
Questions related to Jeff Garzik's proposal<ref name="garzik_bip">[http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf Draft BIP: decentralized economic policy], Jeff Garzik, 12 June 2015 (revised 15 June 2015)</ref> to allow miners to vote on raising and lowering the maximum block size.<br />
<br />
==== What does this proposal do? ====<br />
<br />
# It creates a one-time hard fork that does not automatically change the maximum block size.<br />
<br />
# It allows miners to vote to increase or decrease the maximum block size within the range of 1MB to 32MB. These changes are neither hard forks nor soft forks, but simply rules that all nodes should know about after the initial hard fork.<br />
<br />
==== Does it reduce the risk of a hard fork? ====<br />
<br />
Hard forks are most dangerous when they're done without strong<br />
consensus.<ref name="garzik_bip" /><ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008779.html Consensus changes are not about making a change to the software],<br />
Pieter Wuille, 18 June 2015</ref><br />
<br />
If Garzik's proposal gains strong consensus, it will be as safe as possible<br />
for a hard fork and it will allow increasing the block size up to 32 MB<br />
without any additional risk of a fork.<br />
<br />
==== Why is it limited to 32 megabytes? ====<br />
<br />
According to the draft BIP, "the 32 MB hard fork is largely coincidental -- a whole network upgrade at 32 MB was likely needed anyway."<br />
<br />
=== Lightning Network ===<br />
<br />
Questions related to using the proposed [http://lightning.network/ Lightning network] as a way to scale the number of users Bitcoin can support.<br />
<br />
==== How does transaction security differ from that of Bitcoin? ====<br />
<br />
Transactions on the proposed Lightning network use Bitcoin transactions exclusively to transfer bitcoins<ref name="russell_lightning1">[http://rusty.ozlabs.org/?p=450 Lightning Networks: Part I], Rusty Russell, 30 March 2015</ref>, and so the same security as regular Bitcoin transactions is provided when both a Lightning hub and client are cooperating.<br />
<br />
When a Lightning hub or client refuses to cooperate with the other (maybe because they accidentally went offline), the other party can still receive their full 100% bitcoin balance by closing the payment channel—but they must first wait for a defined amount of time mutually chosen by both the hub and client.<ref>[http://rusty.ozlabs.org/?p=462 Lightning Networks: Part II], Rusty Russell, 1 April 2015</ref><br />
<br />
If one party waits too long to close the payment channel, the other party may be able to steal bitcoins. However, it is possible to delegate the task of closing the channel in an emergency to an unlimited number of hubs around the Internet, so closing the channel on time should be easy.<ref name="russell_lightning4">[http://rusty.ozlabs.org/?p=477 Lightning Networks: Part IV], Rusty Russell, 8 April 2015</ref><br />
<br />
In summary, provided that payment channels are closed on time, the worst that can happen to users is that they may have to wait a few weeks for a channel to fully close before spending the bitcoins they received from it. Their security is otherwise the same as with regular Bitcoin.<br />
<br />
For Lightning hubs, security is slightly worse in the sense that they need to keep a potentially-large amount of funds in a hot wallet<ref name="lightning_paper">[http://lightning.network/lightning-network-paper-DRAFT-0.5.pdf Lightning Network (Draft 0.5)], Section 6.3: Coin Theft via Hacking, Joseph Poon and Thaddeus Dryja</ref>, so they can’t take advantage of the anti-hacking protection offered by cold wallets. Otherwise, Lightning hubs have the same security as clients.<br />
<br />
==== When will Lightning be ready for use? ====<br />
<br />
Lightning requires a basic test implementation (work underway<ref>[https://lists.blockstream.com/pipermail/lightning-dev/2015-June/000018.html Lightning first steps], Rusty Russell, 13 June 2015</ref>), several soft-fork changes to the Bitcoin protocol (work underway<ref>[https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65: CheckLockTimeVerify], Peter Todd, 1 October 2014</ref><ref>[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68: Consensus-enforced transaction replacement], Mark Friedenbach, 28 May 2015</ref>, and wallets need to be updated to support the Lightning network protocol.<ref name="russell_lightning4" /><br />
<br />
Dr. Adam Back has said, "I expect we can get something running inside a year."<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009242.html Reply to Andresen regarding Lightning], Dr. Adam Back, 28 June 2015</ref><br />
<br />
==== Doesn’t Lightning require bigger blocks anyway? ====<br />
<br />
Lightning is block-size neutral. It requires one on-chain transaction to open a channel between a hub and a client, and one on-chain transaction to close a channel.<ref name="russell_lightning1" /> In between it can support an unlimited number of transactions between anyone on the Lightning network.<ref name="lightning_paper" /><br />
<br />
Using the numbers from the Lightning presentation<ref name="lightning_slides">[http://lightning.network/lightning-network.pdf Lightning presentation], Joseph Poon, 23 February 2015</ref>, if people open and close a plausible two channels a year, Lightning can support about 52 million users with the current one-megabyte limit—and each user can make an unlimited number of transactions. Currently, assuming people make an average of only two Bitcoin transactions a day, basic Bitcoin can support only 288,000 users.<br />
<br />
Under these assumptions, Lightning is 180 times (17,900%) more efficient than basic Bitcoin.<br />
<br />
Presumably, if around 30 million people are using Bitcoin via Lightning so that capacity is called into question, it will not be difficult to find consensus to double the block size to two megabytes and bring user capacity up to 105 million. The same goes for later increases to 200 million (4MB), 400 million (8MB), 800 million (16MB), 1.6 billion (32 MB), 3.2 billion (64MB), and all 7 billion living humans (133MB). In each case, all Lightning network participants get unlimited transactions to the other participants.<br />
<br />
For basic Bitcoin to scale to just 2 transactions a day for 7 billion people would require 24-gigabyte blocks.<ref name="lightning_slides" /><br />
<br />
=== Sidechains ===<br />
<br />
==== Real quick, what are sidechains? ====<br />
<br />
Block chains that are separate from Bitcoin’s block chain, but which allow you to receive and spend bitcoins using a two-way peg (2WP).<ref name="sidechains_paper">[https://www.blockstream.com/sidechains.pdf Sidechains paper], Adam Back et al., 22 October 2014</ref> (Although a sidechain can never be more secure than the Bitcoin block chain.<ref>[https://www.reddit.com/r/Bitcoin/comments/39r85g/sidechain_hate/cs5spbg Security limitations of pegged chains], Gregory Maxwell, 14 June 2015</ref>)<br />
<br />
==== Are sidechains a scaling option? ====<br />
<br />
No. Sidechains have the same fundamental scaling problems as Bitcoin does. Moving some transactions to sidechains simply moves some problems elsewhere on the network—the total difficulty of the problem remains the same.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008617.html Sidechains not a direct means for solving any of the scaling problems Bitcoin has], Pieter Wuille, 13 June 2015</ref><br />
<br />
==== But couldn’t I create a sidechain that had 100 GB blocks? ====<br />
<br />
Certainly, sidechain code is open source<ref>[https://github.com/ElementsProject/elements Elements Project]</ref>—so you can create your own sidechain. But you’d still have the difficulty of finding people who are willing to validate 100 GB blocks with their own full nodes.<br />
<br />
==== Do sidechains require a hard fork? ====<br />
<br />
No. Federated sidechains, such as have already been implemented<ref>[https://github.com/ElementsProject/elements/tree/alpha Elements Alpha]</ref>, don’t require any changes to the Bitcoin consensus rules. Merged-mined sidechains, which have not been implemented yet, do require a backwards-compatible soft fork in order to transfer funds between Bitcoin and the sidechain.<ref name="sidechains_paper" /><br />
<br />
== References ==<br />
<references /></div>Amincdhttps://en.bitcoin.it/w/index.php?title=Scalability_FAQ&diff=60391Scalability FAQ2016-02-14T15:51:20Z<p>Amincd: /* How could larger blocks affect proof-of-work (POW) security? */</p>
<hr />
<div>Answers to commonly-asked questions and concerns about scaling Bitcoin, including “level 1” solutions such as increasing the block size and “level 2” solutions such as the proposed Lightning network.<br />
<br />
== Background ==<br />
<br />
Questions about how Bitcoin currently works (related to scaling) as well as questions about the technical terminology related to the scaling discussion.<br />
<br />
=== What is the short history of the block size limit? ===<br />
<br />
''Note: the software now called Bitcoin Core was previously simply called “Bitcoin”.<ref>[https://bitcoin.org/en/release/v0.9.0#rebranding-to-bitcoin-core Bitcoin Core 0.9.0 release notes], Bitcoin.org, 19 March 2014</ref> To avoid confusion with the Bitcoin system, we’ll use the Bitcoin Core name.''<br />
<br />
Bitcoin Core was initially released without an explicit block size limit. However, the code did limit network messages to a maximum of 32 MiB, setting an effective upper bound on block size.<ref>[https://bitcointalk.org/index.php?topic=68121 Earliest known Bitcoin code], <code>src/main.h:17</code></ref><br />
<br />
Around 15 July 2010, Satoshi Nakamoto changed Bitcoin Core’s mining code so that it wouldn’t create any blocks larger than 990,000 bytes.<ref>[https://github.com/bitcoin/bitcoin/commit/a30b56ebe76ffff9f9cc8a6667186179413c6349 Bitcoin Core commit a30b56e], Satoshi Nakamoto, 15 July 2010</ref><br />
<br />
Two months later on 7 September 2010, Nakamoto changed Bitcoin Core’s consensus rules to reject blocks larger than 1,000,000 bytes (1 megabyte) if their block height was higher than 79,400.<ref>[https://github.com/bitcoin/bitcoin/commit/8c9479c6bbbc38b897dc97de9d04e4d5a5a36730 Bitcoin Core commit 8c9479c], Satoshi Nakamoto, 7 September 2010</ref> (Block 79,400 was later produced on 12 September 2010.<ref>[https://www.biteasy.com/blockchain/blocks/000000000021d821ec06be7173f413690bc5c4bc648dfa70b3b6763236f055b7 Block height 79400], dated 12 September 2010</ref>)<br />
<br />
Neither the July nor the September commit message explains the reason for the limit, although the careful attempt to prevent a fork may indicate Nakamoto didn’t consider it an emergency.<br />
<br />
Nakamoto’s subsequent statements supported raising the block size at a later time<ref>[https://bitcointalk.org/index.php?topic=1347.msg15139#msg15139 Increasing the block size when needed], Satoshi Nakamoto, 3 October 2010</ref>, but he never publicly specified a date or set of conditions for the raise.<br />
<br />
Statements by Nakamoto in the summer of 2010 indicate he believed Bitcoin could scale to block sizes far larger 1 megabyte. For example, on 5 August 2010, he wrote that "[W]hatever size micropayments you need will eventually be practical. I think in 5 or 10 years, the bandwidth and storage will seem trivial" and "[microtransactions on the blockchain] can become more practical ... if I implement client-only mode and the number of network nodes consolidates into a smaller number of professional server farms" <ref>[https://bitcointalk.org/index.php?topic=532.msg6306#msg6306 the number of network nodes consolidates into a smaller number of professional server farms]</ref>. <br />
<br />
These statements suggest that the intended purpose of the 1 megabyte limit was not to keep bandwidth and storage requirements for running a Bitcoin node low enough to be practical for personal computers and consumer-grade internet connections, and that the limit would be lifted to accommodate greater demand for transactional capacity.<br />
<br />
=== What is this Transactions Per Second (TPS) limit? ===<br />
<br />
The current block size limit is 1,000,000 bytes (1 megabyte)<ref>[https://github.com/bitcoin/bitcoin/blob/41076aad0cbdfa4c4cf376e345114a5c29086f81/src/consensus/consensus.h#L10 <code>MAX_BLOCK_SIZE</code>], retrieved 2 July 2015</ref>, although a small amount of that space (such as the block header) is not available to store transactions.<ref>[https://bitcoin.org/en/developer-reference#serialized-blocks Block serialization description], Bitcoin.org Developer Reference</ref><br />
<br />
Bitcoin transactions vary in size depending on multiple factors, such as whether they’re spending single-signature inputs or a multiple signature inputs, and how many inputs and outputs they have.<br />
<br />
The simple way to calculate the number of Transactions Per Second (TPS) Bitcoin can handle is to divide the block size limit by the expected average size of transactions, divided by the average number of seconds between blocks (600). For example, if you assume average transactions are 250 bytes,<br />
<br />
<pre>6.6 TPS = 1,000,000 / 250 / 600</pre><br />
<br />
There seems to be general agreement that Bitcoin in 2015 can handle about 3 TPS with the current average size of transactions.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/007986.html Max TPS based on current average transaction size], Mike Hearn, 8 May 2015</ref><ref name="maxwell_not_proposing">[https://www.reddit.com/r/Bitcoin/comments/39yaod/bitcoinorg_position_on_hard_forks/cs7qz5c "No one proposing 3 TPS forever"], Gregory Maxwell, 15 June 2015</ref><br />
<br />
Both old estimates<ref>[[Scalability]], Bitcoin Wiki, retrieved 7 July<br />
2015</ref> and new estimates<ref name="garzik_bip" /> place the<br />
theoretical maximum at 7 TPS with current Bitcoin consensus rules<br />
(including the 1MB block size limit).<br />
<br />
=== What do devs mean by the scaling expressions O(1), O(n), O(n<sup>2</sup>), etc…? ===<br />
<br />
[https://en.wikipedia.org/wiki/Big_O_notation Big O notation] is a shorthand used by computer scientists to describe how well a system scales. Such descriptions are rough approximations meant to help predict potential problems and evaluate potential solutions; they are not usually expected to fully capture all variables.<br />
<br />
* '''O(1)''' means a system has roughly the same properties no matter how big it gets.<br />
* '''O(n)''' means that a system scales linearly: doubling the number of things (users, transactions, etc.) doubles the amount of work.<br />
* '''O(n<sup>2</sup>)''' means that a system scales quadratically : doubling (2x) the number of things quadruples (4x) the amount of work. Often written O(n^2) is places without convenient superscripts.<br />
* Additional examples may be found in the [https://en.wikipedia.org/wiki/Big_O_notation#Orders_of_common_functions Wikipedia article]<br />
<br />
The following subsections show cases where big O notation has been applied to the scaling Bitcoin transaction volume.<br />
<br />
==== O(1) block propagation ====<br />
<br />
Bitcoin Core currently relays unconfirmed transactions and then later relays blocks containing many of the same transactions. This redundant relay can be eliminated to allow miners to propagate large blocks very quickly to active network nodes, and would also significantly reduce miner need for peak bandwidth. Currently most miners use a network<ref name="block_relay_net">[http://bitcoinrelaynetwork.org/ Matt Corallo's block relay network]</ref> that is about 25x more efficient than stock Bitcoin Core<ref>[https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2#i-know-that-you-know IBLT design document], Gavin Andresen, 11 August 2014</ref> and almost equally as effective as O(1) block propagation for current block sizes.<br />
<br />
=== What’s the difference between on-chain and off-chain transactions? ===<br />
<br />
On-chain Bitcoin transactions are those that appear in the Bitcoin block chain. Off-chain transactions are those that transfer ownership of bitcoins without putting a transaction on the block chain.<br />
<br />
Common and proposed off-chain transactions include:<br />
<br />
* '''Exchange transactions:''' when you buy or sell bitcoins, the exchange tracks ownership in a database without putting data in the block chain. Only when you deposit or withdraw bitcoins does the transaction appear on the block chain.<br />
* '''Web wallet internal payments:''' many web wallets allow users of the service to pay other users of the same service using off-chain payments. For example, when one Coinbase user pays another Coinbase user.<br />
* '''Tipping services:''' most tipping services today, such as ChangeTip, use off-chain transactions for everything except deposits and withdrawals.<ref>[https://www.changetip.com/fees ChangeTip fees], retrieved 3 July 2015</ref><br />
* '''Payment channels:''' channels are started using one on-chain transaction and ended using a second on-chain transaction.<ref>[https://bitcoin.org/en/developer-guide#micropayment-channel Micropayment channels], Bitcoin.org Developer Guide</ref> In between can be an essentially unlimited number of off-chain transactions as small as a single satoshi (1/100,000,000th of a bitcoin). Payment channels include those that [https://bitcoinj.github.io/working-with-micropayments exist today] as well as proposed hub-and-spoke channels and the more advanced [http://lightning.network/ Lightning network].<br />
<br />
Approximately 90% to 99% of all bitcoin-denominated payments today are made off-chain.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008844.html Pure off-chain is a weak form of layer 2], Dr. Adam Back, 19 June 2015</ref><br />
<br />
=== What is a fee market? ===<br />
<br />
When you create a Bitcoin transaction, you have the option to pay a [[transaction fee]]. If your software is flexible, you can pay anything from zero fees (a free transaction) to 100% of the value of the transaction (spend-to-fees). This fee is comparable to a tip. The higher it is, the bigger the incentive of the miners to incorporate your transaction into the next block.<br />
<br />
When miners assemble a block, they are free to include whatever transactions they wish. They usually include as many as possible up to the maximum block size and then prioritize the transactions that pay the most fees per kilobyte of data.<ref name="fee_pri">[https://bitcointalk.org/index.php?topic=95837.0 Fee prioritization patch], Gavin Andresen, 26 July 2012</ref> This confirms higher-fee transactions before lower-fee transactions. If blocks become full on a regular basis, users who pay a fee that's too small will have to wait a longer and longer time for their transactions to confirm. At this point, a demand-driven fee market may arise where transactions that pay higher fees get confirmed significantly faster than transactions that pay low fees.<ref name="todd_coinwallet">[https://gist.github.com/petertodd/8e87c782bdf342ef18fb Comments on the CoinWallet.eu tx-flood stress-test], Peter Todd, 22 June 2015</ref><ref name="garzik_bip" /><br />
<br />
In a competitive market, prices are driven by supply and demand and the emerging equilibrium price asymptotically approaches marginal costs over time. However, the current version of Bitcoin limits the supply to 1 MB per block, only allowing demand to adjust. To establish a free market, one would need to come up with a mechanism that allows the number of included transactions per block to adjust dynamically as well. The design of such a mechanism, however, is not trivial. Simply allowing individual miners to include as many transactions as they want is problematic due to the externalities<ref name="exernality">[https://en.wikipedia.org/wiki/Externality Definition of externality], Wikipedia, 26 January 2016</ref> of including additional blocks and explained further in section [[#Should miners be allowed to decide the block size?|'should miners be allowed to decide the block size?']] .<br />
<br />
=== What is the most efficient way to scale Bitcoin? ===<br />
<br />
Remove its decentralization properties, specifically decentralized mining and decentralized full nodes. Mining wastes enormous amounts of electricity to provide a decentralized ledger and full nodes waste an enormous amount of bandwidth and CPU time keeping miners honest.<br />
<br />
If users instead decided to hand authority over to someone they trusted, mining and keeping miners honest wouldn’t be needed. This is how Visa, MasterCard, PayPal, and the rest of the centralized payment systems works—users trust them, and they have no special difficulty scaling to [[scalability|millions of transactions an hour]]. It’s very efficient; it isn’t decentralized.<br />
<br />
=== What is a hard fork, and how does it differ from other types of forks? ===<br />
<br />
The word fork is badly overloaded in Bitcoin development.<br />
<br />
* '''[[hardfork|Hard fork]]:''' a change to the system which is not backwards compatible. Everyone needs to upgrade or things can go wrong.<br />
* '''[[softfork|Soft fork]]:''' a change to the system which is backwards compatible as long as a majority of miners enforce it. Full nodes that don’t upgrade have their security reduced.<br />
* '''Chain fork:''' when there are two are more blocks at the same height on a block chain. This typically happens a few times a week by accident, but it can also indicate more severe problems.<br />
* '''[https://en.wikipedia.org/wiki/Fork_%28software_development%29 Software fork]:''' using the code from an open source project to create a different project.<br />
* '''[https://help.github.com/articles/fork-a-repo/ Git/GitHub fork]:''' a way for developers to write and test new features before contributing them to a project.<br />
<br />
(There are other types of software-related forks, but they don’t tend to cause as much confusion.)<br />
<br />
=== What are the block size soft limits? ===<br />
<br />
Bitcoin Core has historically come pre-configured to limit blocks it mines to certain sizes.<ref name="fee_pri" /> These “limits” aren’t restrictions placed on miners by other miners or nodes, but rather configuration options that help miners produce reasonably-sized blocks.<br />
<br />
Miners can change their soft limit size (up to 1 MB) using <code>-blockmaxsize=&lt;size&gt;</code><br />
<br />
Default soft limits at various times:<br />
<br />
* '''July 2012:''' <code>-blockmaxsize</code> option created and set to default 250 KB soft limit<ref>[https://github.com/bitcoin/bitcoin/commit/c555400ca134991e39d5e3a565fcd2215abe56f6 Bitcoin Core commit c555400], Gavin Andresen, 12 July 2012</ref><br />
* '''November 2013:''' Raised to 750KB<ref>[https://github.com/bitcoin/bitcoin/commit/ad898b40aaf06c1cc7ac12e953805720fc9217c0 Bitcoin Core commit ad898b40], Gavin Andresen, 27 November 2013</ref><br />
* '''June 2015:''' Raise to 1 MB suggested<ref>[https://github.com/bitcoin/bitcoin/pull/6231 Bitcoin Core pull #6231], Chris Wheeler, 4 June 2015</ref><br />
<br />
== General Block Size Increase Theory ==<br />
<br />
Questions about increasing the block size in general, not related to any<br />
specific proposal.<br />
<br />
==== Why are some people in favor of keeping the block size at 1 MB forever? ====<br />
<br />
It is commonly claimed<ref name="garzik_bip" /><ref>[https://epicenterbitcoin.com/podcast/082/ Epicenter Bitcoin podcast #82], Mike Hearn (interviewed), 8 June 2015</ref> that there are people opposed to ever raising the maximum block size limit, but no Bitcoin developers have suggested keeping the maximum block size at one megabyte forever.<ref name="maxwell_not_proposing" /><br />
<br />
All developers support raising the maximum size at some point<ref>[https://www.reddit.com/r/Bitcoin/comments/39kqzs/how_about_a_softfork_optin_blocksize_increase/cs5hj8l Nothing magic about 1MB], Dr. Adam Back, 13 June 2015</ref><ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008328.html Regarding size-independent new block propagation], Pieter Wuille, 28 May 2015</ref>—they just disagree about whether now is the correct time.<br />
<br />
==== Should miners be allowed to decide the block size? ====<br />
<br />
A block may include as little as a single transaction, so miners can always restrict block size. Letting miners choose the maximum block size is more problematic for several reasons:<br />
<br />
# '''Miners profit, others pay the cost:''' bigger blocks earn miners more fees, but miners don’t need to store those blocks for more than a few days.<ref>[https://github.com/bitcoin/bitcoin/pull/5863 Bitcoin Core pull #5863 adding pruning functionality], Suhas Daftuar et al., 6 March 2015</ref> Other users who want full validation security, or who provide services to lightweight wallets, pay the costs of downloading and storing those larger blocks.<br />
# '''Bigger miners can afford more bandwidth:''' each miner needs to download every transaction that will be included in block,<ref name="maxwell_correcting_assumptions" /> which means that they all need to pay for high-speed connections. However, a miner with 8.3% of total hash rate can take that cost out of the about 300 BTC they make a day, while a miner with only 0.7% of total hash rate has to take that cost out of only 25 BTC a day. This means bigger miners may logically choose to make bigger blocks even though it may further centralize mining.<br />
# '''Centralized hardware production:''' only a few companies in the world produce efficient mining equipment, and many of them have chosen to stop selling to the public.<ref>[http://blogs.wsj.com/venturecapital/2014/09/05/for-kncminer-time-to-forget-selling-bitcoin-machines-to-at-home-miners/ KnCMiner to stop selling to home miners], Wall Street Journal, Yuliya Chernova, 5 September 2014</ref> This prevents ordinary Bitcoin users from participating in the process even if they were willing to pay for mining equipment.<br />
# '''Voting by hash rate favors larger miners:''' voting based on hash rate allows the current hash rate majority (or super-majority) to enforce conditions on the minority. This is similar to a lobby of large businesses being able to get laws passed that may hurt smaller businesses.<ref>[https://www.reddit.com/r/Bitcoin/comments/39kzyt/draft_bip_100_soft_fork_block_size_increase/cs5gvak Miners choosing the block size limit is ill-advised], Meni Rosenfeld, 13 June 2015</ref><br />
# '''Miners may not care about users:''' this was demonstrated during the [[July 2015 Forks]] where even after miners lost over $50,000 USD in income from mining invalid chains, and even after they were told that long forks harm users, they continued to mine improperly.<ref>[https://bitcointalk.org/index.php?topic=700411.msg11790734#msg11790734 Intention to continue SPV mining], Wang Chun, 4 July 2015</ref><br />
<br />
However, there are also possible justifications for letting miners choose the block size:<br />
<br />
# '''Authenticated participants:''' miners are active participants in Bitcoin, and they can prove it by adding data to the blocks they create.<ref>[https://bitcoin.org/en/developer-reference#term-coinbase-field Coinbase field], Bitcoin.org Developer Reference</ref> It is much harder to prove people on Reddit, BitcoinTalk, and elsewhere are real people with an active stake in Bitcoin.<br />
# '''Bigger blocks may cost miners:''' small miners and poorly-connected miners are at a disadvantage if larger blocks are produced<ref name="wuille_centralization" />, and even large and well-connected miners may find that large blocks reduce their profit percentage if the cost of bandwidth rises too high or their stale rate increases.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008355.html F2Pool block size concerns], Chun Wang, 29 May 2015</ref><br />
<br />
==== How could a block size increase affect user security? ====<br />
<br />
Bitcoin’s security is highly dependent on the number of active users who protect their bitcoins with a full node like Bitcoin Core. The more active users of full nodes, the harder it is for miners to trick users into accepting fake bitcoins or other frauds.<ref>[https://medium.com/@lopp/bitcoin-nodes-how-many-is-enough-9b8e8f6fd2cf Bitcoin nodes: how many is enough?], Jameson Lopp, 7 June 2015</ref><br />
<br />
Full nodes need to download and verify every block, and most nodes also store blocks plus relay transactions, full blocks, and filtered blocks to other users on the network. The bigger blocks become, the more difficult it becomes to do all this, so it is expected that bigger blocks will both reduce the number of users who currently run full nodes and suppress the number of users who decide to start running a full node later.<ref>[https://www.reddit.com/r/Bitcoin/comments/3bae2d/amir_taaki_on_raising_the_block_size_a_lot_of/cslcgmw Block size increases-only will create problems], Dr. Adam Back, 28 June 2015</ref><br />
<br />
In addition, full blocks may increase mining centralization<ref name="wuille_centralization" /> at a time when mining is already so centralized that it makes it easy to reverse transactions which have been confirmed multiple times.<ref>[http://bitcoin.stackexchange.com/questions/32562/when-to-worry-about-1-confirmation-payments/32564#32564 When to worry about one-confirmation payments], David A. Harding, 17 November 2014</ref><br />
<br />
==== How could larger blocks affect proof-of-work (POW) security? ====<br />
<br />
Proof of work security is dependent on how much money miners spend on mining equipment. However, to effectively mine blocks, miners also need to spend money on bandwidth to receive new transactions and blocks created by other miners; CPUs to validate received transactions and blocks; and bandwidth to upload new blocks. These additional costs don’t directly contribute to POW security.<ref name="maxwell_correcting_assumptions">[https://www.reddit.com/r/Bitcoin/comments/39tgno/letting_miners_vote_on_the_maximum_block_size_is/cs6rek5 Correcting wrong assumptions about mining], Gregory Maxwell, 15 June 2015</ref><br />
<br />
As block sizes increase, the amount of bandwidth and CPU required also increases. If block sizes increase faster than the costs of bandwidth and CPU decrease, miners will have less money for POW security relative to the gross income they earn.<br />
<br />
In addition, larger blocks have a higher risk of becoming stale (orphaned)<ref name="rusty_dsl" />, which directly correlates to lost POW security. For example, if the network average stale rate is 10%, then 10% of POW performed isn't protecting transactions on the block chain.<br />
<br />
Conversely, larger blocks that result in a lower per transaction fee can increase the demand for on-chain transactions, and result in total transaction fees earned by miners increasing despite a lower average transaction fee. This would increase network security by increasing the revenue that supports Proof of Work generation. <br />
<br />
Without an increase in the block size from 1 megabyte, Bitcoin needs $1.50 worth of BTC paid in fees per transaction once block subsidies disappear to maintain current mining revenue and economic expenditure on network security. The required fee per transaction for maintaining current economic expenditure levels once the subsidy disappears decreases as the block size, and with it the maximum on-chain transaction throughput, increases. <br />
<br />
As a result of the sensitivity of demand to price increases, growth in the Bitcoin economy, and thus growth in the fees paid to secure the Bitcoin network, could be stunted if the block size is not allowed to increase sufficiently.<br />
<br />
=== What happens if blocks aren't big enough to include all pending transactions? ===<br />
<br />
This is already the case more often than not<ref>[http://statoshi.info/dashboard/db/transactions?from=1433297061121&to=1435889061123 Statoshi.info mempool queue June to July 2015]</ref>, so we know that miners will simply queue transactions. The transactions eligible for block inclusion that pay the highest fee per kilobyte will be confirmed earlier than transactions that pay comparatively lower fees.<ref name="fee_pri" /><br />
<br />
What happens from there is debated:<br />
<br />
* BitcoinJ lead developer Mike Hearn believes there would be “crashing nodes, a swelling transaction backlog, a sudden spike in double spending, [and] skyrocketing fees.”<ref>[https://medium.com/@octskyward/crash-landing-f5cc19908e32 Crash Landing], Mike Hearn, 7 May 2015</ref><br />
* Bitcoin Foundation chief scientist Gavin Andresen believes that the “average transaction fee paid will rise, people or applications unwilling or unable to pay the rising fees will stop submitting transactions, [and] people and businesses will shelve plans to use Bitcoin, stunting growth and adoption.” <ref>[https://github.com/bitcoin/bitcoin/pull/6341 Bitcoin Core pull #6341], Gavin Andresen, 26 June 2015</ref><br />
* Bitcoin Core developer Pieter Wuille replies to Andresen’s comment above: “Is it fair to summarize this as ‘Some use cases won’t fit any more, people will decide to no longer use the blockchain for these purposes, and the fees will adapt.’? I think that is already happening […] I don’t think we should be afraid of this change or try to stop it.” <ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009098.html The need for larger blocks], Pieter Wuille, 26 June 2015</ref><br />
* Bitcoin Core developer Jeff Garzik writes, "as blocks get full and the bidding war ensues, the bitcoin user experience rapidly degrades to poor. In part due to bitcoin wallet software’s relative immaturity, and in part due to bitcoin’s settlement based design, the end user experience of their transaction competing for block size results in erratic, and unpredictably extended validation times."<ref name="garzik_bip" /><br />
<br />
== Specific Scaling Proposals ==<br />
<br />
=== Andresen-Hearn Block Size Increase Proposals ===<br />
<br />
Questions about the series of related proposals by Gavin Andresen and Mike Hearn to use a hard fork to raise the maximum block size, thereby allowing miners to include more on-chain transactions. As of July 2015, the current focus is [https://github.com/bitcoin/bips/pull/163 BIP101].<br />
<br />
==== What is the major advantage of this proposal? ====<br />
<br />
''Bitcoin can support many more users.'' Assuming earliest possible adoption, 250 bytes per on-chain transaction, 144 blocks per day, and 2 transaction a day per user, Bitcoin can support about,<br />
<br />
* 288,000 users in 2015<br />
* 2,304,000 users in 2016 (800% increase)<br />
* 4,608,000 in 2018 (1,600%)<br />
* 9,216,000 in 2020 (3,200%)<br />
* 18,432,000 in 2022 (6,400%)<br />
* 36,864,000 in 2024 (12,800%)<br />
* 73,728,000 in 2026 (25,600%)<br />
* 147,456,000 in 2028 (51,200%)<br />
* 294,912,000 in 2030 (102,400%)<br />
* 589,824,000 in 2032 (204,800%)<br />
* 1,179,648,000 in 2034 (409,600%<br />
* 2,359,296,000 in 2036 (819,200%)<br />
<br />
==== What is the major disadvantage of this proposal? ====<br />
<br />
''The total cost of remaining decentralized will be high.'' Assuming earliest possible adoption and that the ratio of total users to full node operators remains the same as today, the total estimated amount of work necessary to maintain the decentralized system under the [[#O.28n2.29_network_total_validation_resource_requirements|O(<sup>2</sup>) scaling model]] will be,<br />
<br />
* 100% of today’s work in 2015<br />
* 6,400% in 2016<br />
* 25,600% in 2018<br />
* 102,400% in 2020<br />
* 409,600% in 2022<br />
* 1,638,400% in 2024<br />
* 6,553,600% in 2026<br />
* 26,214,400% in 2028<br />
* 104,857,600% in 2030<br />
* 419,430,400% in 2032<br />
* 1,677,721,600% in 2034<br />
* 6,710,886,400% in 2036<br />
<br />
For example, if the total amount spent on running full nodes today (not counting mining) is $100 thousand per year, the estimated cost for the same level of decentralization in 2036 will be $6.7 trillion per year if validation costs stay the same. (They'll certainly go down, but algorithmic and hardware improvements probably won't eliminate an approximate 6,710,886,400% cost increase.)<br />
<br />
==== What are the dangers of the proposed hard fork? ====<br />
<br />
Under the current proposal, 75% of miners must indicate that they agree to accept blocks up to 8 MB in size.<ref name="bip101">[https://github.com/bitcoin/bips/pull/163 BIP101], Gavin Andresen, 24 June 2016</ref> After the change goes into effect, if any miner creates a block larger than 1 MB, all nodes which have not upgraded yet will reject the block.<ref>[https://bitcoin.org/en/developer-guide#consensus-rule-changes Consensus rule changes], Bitcoin.org Developer Guide</ref><br />
<br />
If all full nodes have upgraded, or very close to all nodes, there should be no practical effect. If a significant number of full nodes have not upgraded, they will continue using a different block chain than the upgraded users, with the following consequences:<br />
<br />
* Bitcoins received from before the fork can be spent twice, once on both sides of the fork. This creates a high double spend risk.<br />
* Bitcoins received after the fork are only guaranteed to be spendable on the side of the fork they were received on. This means some users will have to lose money to restore Bitcoin to a single chain.<br />
<br />
Users of hosted wallets (Coinbase, BlockChain.info, etc.) will use whatever block chain their host chooses. Users of lightweight P2P SPV wallets will use the [[Thin Client Security|longest chain they know of]], which may not be the actual longest chain if they only connect to nodes on the shorter chain. Users of non-P2P SPV wallets, like Electrum, will use whatever chain is used by the server they connect to.<br />
<br />
If a bad hard fork like this happens, it will likely cause large-scale confusion and make Bitcoin very hard to use until the situation is resolved.<br />
<br />
==== What is the deployment schedule for BIP 101? ====<br />
<br />
* The patch needs to be accepted into Bitcoin Core, Bitcoin XT, or both.<br />
* If accepted into Bitcoin Core, miners using that software will need to upgrade (this probably requires a new released version of Bitcoin Core). If accepted only into Bitcoin XT, miners will need to switch to using XT.<br />
* After 75% of miners have upgraded, 8MB blocks will become allowed at the the latest of (1) 11 January 2016 or (2) two weeks after the 75% upgrade threshold.<ref name="bip101" /><br />
* After the effective date has passed, any miner may create a block larger than 8MB. When a miner does this, upgraded full nodes will accept that block and non-upgraded full nodes will reject it, forking the network.<ref name="bip101" /> See [[#What_are_the_dangers_of_the_proposed_hard_fork.3F|hard fork dangers]] for what his might mean.<br />
<br />
==== Will miners go straight from 1 MB blocks to 8 MB blocks? ====<br />
<br />
That would be highly unlikely. Uploading an 8 MB block currently takes significantly more time than uploading a 1 MB block<ref name="rusty_dsl">[http://rusty.ozlabs.org/?p=509 Mining on a home DSL connection test results], Rusty Russell, 19 June 2015</ref>, even with the roughly 25x reduction in size available from use of Matt Corallo’s block relay network.<ref name="block_relay_net" /><br />
<br />
The longer it takes to upload a block, the higher the risk it will become a stale block—meaning the miner who created it will not receive the block subsidy or transaction fees (currently about 25 BTC per block).<br />
<br />
However, if technology like Invertible Bloom Lookup Tables (IBLTs) is deployed and found to work as expected<ref name="iblt">[https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2 O(1) block propagation], Gavin Andresen, 8 August 2014</ref>, or if mining [[#What_is_the_most_efficient_way_to_scale_Bitcoin.3F|centralizes further]], adding additional transactions may not have a significant enough cost to discourage miners from creating full blocks. In that case, blocks will be filled as soon as there are enough people wanting to make transactions paying the default relay fee<ref>[https://github.com/bitcoin/bitcoin/pull/3305 Bitcoin Core pull #3305 dropping default fees], Mike Hearn, 22 November 2013</ref> of 0.00001000 BTC/kilobyte.<br />
<br />
==== What tests have been performed related to this proposal? ====<br />
<br />
* '''20MB block processing''' (Gavin Andresen) “if we increased the maximum block size to 20 megabytes tomorrow, and every single miner decided to start creating 20MB blocks and there was a sudden increase in the number of transactions on the network to fill up those blocks… the 0.10.0 version of [Bitcoin Core] would run just fine.”<ref>[http://gavintech.blogspot.com/2015/01/twenty-megabytes-testing-results.html Twenty megabyte block testing], Gavin Andresen, 20 January 2015</ref> (ellipses in original)<br />
* '''Mining &amp; relay simulation''' (Gavin Andresen) “if blocks take 20 seconds to propagate, a network with a miner that has 30% of the hashing power will get 30.3% of the blocks.”<ref>[http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners Are bigger blocks better for bigger miners?], Gavin Andresen, 22 May 2015</ref><br />
* '''Mining on a home DSL connection''' (Rusty Russell) “Using the rough formula of 1-exp(-t/600), I would expect orphan rates of 10.5% generating 1MB blocks, and 56.6% with 8MB blocks; that’s a huge cut in expected profits.”<ref name="rusty_dsl" /><br />
* '''Mining centralization pressure''' (Pieter Wuille) “[This] does very clearly show the effects of larger blocks on centralization pressure of the system.”<ref name="wuille_centralization">[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008581.html Mining centralization pressure from non-uniform propagation speed], Pieter Wuille, 12 June 2015</ref><br />
<br />
<br />
=== Garzik Miner Block Size Voting Proposal (AKA BIP100) ===<br />
<br />
''Note, BIP 100 is the marketing name for this proposal. No BIP number<br />
has yet been publicly requested, and the number assigned is unlikely to<br />
be 100.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-May/005756.html<br />
Prenumbered BIP naming], Gregory Maxwell, 12 May 2014</ref>''<br />
<br />
Questions related to Jeff Garzik's proposal<ref name="garzik_bip">[http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf Draft BIP: decentralized economic policy], Jeff Garzik, 12 June 2015 (revised 15 June 2015)</ref> to allow miners to vote on raising and lowering the maximum block size.<br />
<br />
==== What does this proposal do? ====<br />
<br />
# It creates a one-time hard fork that does not automatically change the maximum block size.<br />
<br />
# It allows miners to vote to increase or decrease the maximum block size within the range of 1MB to 32MB. These changes are neither hard forks nor soft forks, but simply rules that all nodes should know about after the initial hard fork.<br />
<br />
==== Does it reduce the risk of a hard fork? ====<br />
<br />
Hard forks are most dangerous when they're done without strong<br />
consensus.<ref name="garzik_bip" /><ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008779.html Consensus changes are not about making a change to the software],<br />
Pieter Wuille, 18 June 2015</ref><br />
<br />
If Garzik's proposal gains strong consensus, it will be as safe as possible<br />
for a hard fork and it will allow increasing the block size up to 32 MB<br />
without any additional risk of a fork.<br />
<br />
==== Why is it limited to 32 megabytes? ====<br />
<br />
According to the draft BIP, "the 32 MB hard fork is largely coincidental -- a whole network upgrade at 32 MB was likely needed anyway."<br />
<br />
=== Lightning Network ===<br />
<br />
Questions related to using the proposed [http://lightning.network/ Lightning network] as a way to scale the number of users Bitcoin can support.<br />
<br />
==== How does transaction security differ from that of Bitcoin? ====<br />
<br />
Transactions on the proposed Lightning network use Bitcoin transactions exclusively to transfer bitcoins<ref name="russell_lightning1">[http://rusty.ozlabs.org/?p=450 Lightning Networks: Part I], Rusty Russell, 30 March 2015</ref>, and so the same security as regular Bitcoin transactions is provided when both a Lightning hub and client are cooperating.<br />
<br />
When a Lightning hub or client refuses to cooperate with the other (maybe because they accidentally went offline), the other party can still receive their full 100% bitcoin balance by closing the payment channel—but they must first wait for a defined amount of time mutually chosen by both the hub and client.<ref>[http://rusty.ozlabs.org/?p=462 Lightning Networks: Part II], Rusty Russell, 1 April 2015</ref><br />
<br />
If one party waits too long to close the payment channel, the other party may be able to steal bitcoins. However, it is possible to delegate the task of closing the channel in an emergency to an unlimited number of hubs around the Internet, so closing the channel on time should be easy.<ref name="russell_lightning4">[http://rusty.ozlabs.org/?p=477 Lightning Networks: Part IV], Rusty Russell, 8 April 2015</ref><br />
<br />
In summary, provided that payment channels are closed on time, the worst that can happen to users is that they may have to wait a few weeks for a channel to fully close before spending the bitcoins they received from it. Their security is otherwise the same as with regular Bitcoin.<br />
<br />
For Lightning hubs, security is slightly worse in the sense that they need to keep a potentially-large amount of funds in a hot wallet<ref name="lightning_paper">[http://lightning.network/lightning-network-paper-DRAFT-0.5.pdf Lightning Network (Draft 0.5)], Section 6.3: Coin Theft via Hacking, Joseph Poon and Thaddeus Dryja</ref>, so they can’t take advantage of the anti-hacking protection offered by cold wallets. Otherwise, Lightning hubs have the same security as clients.<br />
<br />
==== When will Lightning be ready for use? ====<br />
<br />
Lightning requires a basic test implementation (work underway<ref>[https://lists.blockstream.com/pipermail/lightning-dev/2015-June/000018.html Lightning first steps], Rusty Russell, 13 June 2015</ref>), several soft-fork changes to the Bitcoin protocol (work underway<ref>[https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65: CheckLockTimeVerify], Peter Todd, 1 October 2014</ref><ref>[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68: Consensus-enforced transaction replacement], Mark Friedenbach, 28 May 2015</ref>, and wallets need to be updated to support the Lightning network protocol.<ref name="russell_lightning4" /><br />
<br />
Dr. Adam Back has said, "I expect we can get something running inside a year."<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009242.html Reply to Andresen regarding Lightning], Dr. Adam Back, 28 June 2015</ref><br />
<br />
==== Doesn’t Lightning require bigger blocks anyway? ====<br />
<br />
Lightning is block-size neutral. It requires one on-chain transaction to open a channel between a hub and a client, and one on-chain transaction to close a channel.<ref name="russell_lightning1" /> In between it can support an unlimited number of transactions between anyone on the Lightning network.<ref name="lightning_paper" /><br />
<br />
Using the numbers from the Lightning presentation<ref name="lightning_slides">[http://lightning.network/lightning-network.pdf Lightning presentation], Joseph Poon, 23 February 2015</ref>, if people open and close a plausible two channels a year, Lightning can support about 52 million users with the current one-megabyte limit—and each user can make an unlimited number of transactions. Currently, assuming people make an average of only two Bitcoin transactions a day, basic Bitcoin can support only 288,000 users.<br />
<br />
Under these assumptions, Lightning is 180 times (17,900%) more efficient than basic Bitcoin.<br />
<br />
Presumably, if around 30 million people are using Bitcoin via Lightning so that capacity is called into question, it will not be difficult to find consensus to double the block size to two megabytes and bring user capacity up to 105 million. The same goes for later increases to 200 million (4MB), 400 million (8MB), 800 million (16MB), 1.6 billion (32 MB), 3.2 billion (64MB), and all 7 billion living humans (133MB). In each case, all Lightning network participants get unlimited transactions to the other participants.<br />
<br />
For basic Bitcoin to scale to just 2 transactions a day for 7 billion people would require 24-gigabyte blocks.<ref name="lightning_slides" /><br />
<br />
=== Sidechains ===<br />
<br />
==== Real quick, what are sidechains? ====<br />
<br />
Block chains that are separate from Bitcoin’s block chain, but which allow you to receive and spend bitcoins using a two-way peg (2WP).<ref name="sidechains_paper">[https://www.blockstream.com/sidechains.pdf Sidechains paper], Adam Back et al., 22 October 2014</ref> (Although a sidechain can never be more secure than the Bitcoin block chain.<ref>[https://www.reddit.com/r/Bitcoin/comments/39r85g/sidechain_hate/cs5spbg Security limitations of pegged chains], Gregory Maxwell, 14 June 2015</ref>)<br />
<br />
==== Are sidechains a scaling option? ====<br />
<br />
No. Sidechains have the same fundamental scaling problems as Bitcoin does. Moving some transactions to sidechains simply moves some problems elsewhere on the network—the total difficulty of the problem remains the same.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008617.html Sidechains not a direct means for solving any of the scaling problems Bitcoin has], Pieter Wuille, 13 June 2015</ref><br />
<br />
==== But couldn’t I create a sidechain that had 100 GB blocks? ====<br />
<br />
Certainly, sidechain code is open source<ref>[https://github.com/ElementsProject/elements Elements Project]</ref>—so you can create your own sidechain. But you’d still have the difficulty of finding people who are willing to validate 100 GB blocks with their own full nodes.<br />
<br />
==== Do sidechains require a hard fork? ====<br />
<br />
No. Federated sidechains, such as have already been implemented<ref>[https://github.com/ElementsProject/elements/tree/alpha Elements Alpha]</ref>, don’t require any changes to the Bitcoin consensus rules. Merged-mined sidechains, which have not been implemented yet, do require a backwards-compatible soft fork in order to transfer funds between Bitcoin and the sidechain.<ref name="sidechains_paper" /><br />
<br />
== References ==<br />
<references /></div>Amincdhttps://en.bitcoin.it/w/index.php?title=Scalability_FAQ&diff=60390Scalability FAQ2016-02-14T15:39:09Z<p>Amincd: /* O(n2) network total validation resource requirements */ deleted - number of transactions per user does not increase in proportion to number of users</p>
<hr />
<div>Answers to commonly-asked questions and concerns about scaling Bitcoin, including “level 1” solutions such as increasing the block size and “level 2” solutions such as the proposed Lightning network.<br />
<br />
== Background ==<br />
<br />
Questions about how Bitcoin currently works (related to scaling) as well as questions about the technical terminology related to the scaling discussion.<br />
<br />
=== What is the short history of the block size limit? ===<br />
<br />
''Note: the software now called Bitcoin Core was previously simply called “Bitcoin”.<ref>[https://bitcoin.org/en/release/v0.9.0#rebranding-to-bitcoin-core Bitcoin Core 0.9.0 release notes], Bitcoin.org, 19 March 2014</ref> To avoid confusion with the Bitcoin system, we’ll use the Bitcoin Core name.''<br />
<br />
Bitcoin Core was initially released without an explicit block size limit. However, the code did limit network messages to a maximum of 32 MiB, setting an effective upper bound on block size.<ref>[https://bitcointalk.org/index.php?topic=68121 Earliest known Bitcoin code], <code>src/main.h:17</code></ref><br />
<br />
Around 15 July 2010, Satoshi Nakamoto changed Bitcoin Core’s mining code so that it wouldn’t create any blocks larger than 990,000 bytes.<ref>[https://github.com/bitcoin/bitcoin/commit/a30b56ebe76ffff9f9cc8a6667186179413c6349 Bitcoin Core commit a30b56e], Satoshi Nakamoto, 15 July 2010</ref><br />
<br />
Two months later on 7 September 2010, Nakamoto changed Bitcoin Core’s consensus rules to reject blocks larger than 1,000,000 bytes (1 megabyte) if their block height was higher than 79,400.<ref>[https://github.com/bitcoin/bitcoin/commit/8c9479c6bbbc38b897dc97de9d04e4d5a5a36730 Bitcoin Core commit 8c9479c], Satoshi Nakamoto, 7 September 2010</ref> (Block 79,400 was later produced on 12 September 2010.<ref>[https://www.biteasy.com/blockchain/blocks/000000000021d821ec06be7173f413690bc5c4bc648dfa70b3b6763236f055b7 Block height 79400], dated 12 September 2010</ref>)<br />
<br />
Neither the July nor the September commit message explains the reason for the limit, although the careful attempt to prevent a fork may indicate Nakamoto didn’t consider it an emergency.<br />
<br />
Nakamoto’s subsequent statements supported raising the block size at a later time<ref>[https://bitcointalk.org/index.php?topic=1347.msg15139#msg15139 Increasing the block size when needed], Satoshi Nakamoto, 3 October 2010</ref>, but he never publicly specified a date or set of conditions for the raise.<br />
<br />
Statements by Nakamoto in the summer of 2010 indicate he believed Bitcoin could scale to block sizes far larger 1 megabyte. For example, on 5 August 2010, he wrote that "[W]hatever size micropayments you need will eventually be practical. I think in 5 or 10 years, the bandwidth and storage will seem trivial" and "[microtransactions on the blockchain] can become more practical ... if I implement client-only mode and the number of network nodes consolidates into a smaller number of professional server farms" <ref>[https://bitcointalk.org/index.php?topic=532.msg6306#msg6306 the number of network nodes consolidates into a smaller number of professional server farms]</ref>. <br />
<br />
These statements suggest that the intended purpose of the 1 megabyte limit was not to keep bandwidth and storage requirements for running a Bitcoin node low enough to be practical for personal computers and consumer-grade internet connections, and that the limit would be lifted to accommodate greater demand for transactional capacity.<br />
<br />
=== What is this Transactions Per Second (TPS) limit? ===<br />
<br />
The current block size limit is 1,000,000 bytes (1 megabyte)<ref>[https://github.com/bitcoin/bitcoin/blob/41076aad0cbdfa4c4cf376e345114a5c29086f81/src/consensus/consensus.h#L10 <code>MAX_BLOCK_SIZE</code>], retrieved 2 July 2015</ref>, although a small amount of that space (such as the block header) is not available to store transactions.<ref>[https://bitcoin.org/en/developer-reference#serialized-blocks Block serialization description], Bitcoin.org Developer Reference</ref><br />
<br />
Bitcoin transactions vary in size depending on multiple factors, such as whether they’re spending single-signature inputs or a multiple signature inputs, and how many inputs and outputs they have.<br />
<br />
The simple way to calculate the number of Transactions Per Second (TPS) Bitcoin can handle is to divide the block size limit by the expected average size of transactions, divided by the average number of seconds between blocks (600). For example, if you assume average transactions are 250 bytes,<br />
<br />
<pre>6.6 TPS = 1,000,000 / 250 / 600</pre><br />
<br />
There seems to be general agreement that Bitcoin in 2015 can handle about 3 TPS with the current average size of transactions.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/007986.html Max TPS based on current average transaction size], Mike Hearn, 8 May 2015</ref><ref name="maxwell_not_proposing">[https://www.reddit.com/r/Bitcoin/comments/39yaod/bitcoinorg_position_on_hard_forks/cs7qz5c "No one proposing 3 TPS forever"], Gregory Maxwell, 15 June 2015</ref><br />
<br />
Both old estimates<ref>[[Scalability]], Bitcoin Wiki, retrieved 7 July<br />
2015</ref> and new estimates<ref name="garzik_bip" /> place the<br />
theoretical maximum at 7 TPS with current Bitcoin consensus rules<br />
(including the 1MB block size limit).<br />
<br />
=== What do devs mean by the scaling expressions O(1), O(n), O(n<sup>2</sup>), etc…? ===<br />
<br />
[https://en.wikipedia.org/wiki/Big_O_notation Big O notation] is a shorthand used by computer scientists to describe how well a system scales. Such descriptions are rough approximations meant to help predict potential problems and evaluate potential solutions; they are not usually expected to fully capture all variables.<br />
<br />
* '''O(1)''' means a system has roughly the same properties no matter how big it gets.<br />
* '''O(n)''' means that a system scales linearly: doubling the number of things (users, transactions, etc.) doubles the amount of work.<br />
* '''O(n<sup>2</sup>)''' means that a system scales quadratically : doubling (2x) the number of things quadruples (4x) the amount of work. Often written O(n^2) is places without convenient superscripts.<br />
* Additional examples may be found in the [https://en.wikipedia.org/wiki/Big_O_notation#Orders_of_common_functions Wikipedia article]<br />
<br />
The following subsections show cases where big O notation has been applied to the scaling Bitcoin transaction volume.<br />
<br />
==== O(1) block propagation ====<br />
<br />
Bitcoin Core currently relays unconfirmed transactions and then later relays blocks containing many of the same transactions. This redundant relay can be eliminated to allow miners to propagate large blocks very quickly to active network nodes, and would also significantly reduce miner need for peak bandwidth. Currently most miners use a network<ref name="block_relay_net">[http://bitcoinrelaynetwork.org/ Matt Corallo's block relay network]</ref> that is about 25x more efficient than stock Bitcoin Core<ref>[https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2#i-know-that-you-know IBLT design document], Gavin Andresen, 11 August 2014</ref> and almost equally as effective as O(1) block propagation for current block sizes.<br />
<br />
=== What’s the difference between on-chain and off-chain transactions? ===<br />
<br />
On-chain Bitcoin transactions are those that appear in the Bitcoin block chain. Off-chain transactions are those that transfer ownership of bitcoins without putting a transaction on the block chain.<br />
<br />
Common and proposed off-chain transactions include:<br />
<br />
* '''Exchange transactions:''' when you buy or sell bitcoins, the exchange tracks ownership in a database without putting data in the block chain. Only when you deposit or withdraw bitcoins does the transaction appear on the block chain.<br />
* '''Web wallet internal payments:''' many web wallets allow users of the service to pay other users of the same service using off-chain payments. For example, when one Coinbase user pays another Coinbase user.<br />
* '''Tipping services:''' most tipping services today, such as ChangeTip, use off-chain transactions for everything except deposits and withdrawals.<ref>[https://www.changetip.com/fees ChangeTip fees], retrieved 3 July 2015</ref><br />
* '''Payment channels:''' channels are started using one on-chain transaction and ended using a second on-chain transaction.<ref>[https://bitcoin.org/en/developer-guide#micropayment-channel Micropayment channels], Bitcoin.org Developer Guide</ref> In between can be an essentially unlimited number of off-chain transactions as small as a single satoshi (1/100,000,000th of a bitcoin). Payment channels include those that [https://bitcoinj.github.io/working-with-micropayments exist today] as well as proposed hub-and-spoke channels and the more advanced [http://lightning.network/ Lightning network].<br />
<br />
Approximately 90% to 99% of all bitcoin-denominated payments today are made off-chain.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008844.html Pure off-chain is a weak form of layer 2], Dr. Adam Back, 19 June 2015</ref><br />
<br />
=== What is a fee market? ===<br />
<br />
When you create a Bitcoin transaction, you have the option to pay a [[transaction fee]]. If your software is flexible, you can pay anything from zero fees (a free transaction) to 100% of the value of the transaction (spend-to-fees). This fee is comparable to a tip. The higher it is, the bigger the incentive of the miners to incorporate your transaction into the next block.<br />
<br />
When miners assemble a block, they are free to include whatever transactions they wish. They usually include as many as possible up to the maximum block size and then prioritize the transactions that pay the most fees per kilobyte of data.<ref name="fee_pri">[https://bitcointalk.org/index.php?topic=95837.0 Fee prioritization patch], Gavin Andresen, 26 July 2012</ref> This confirms higher-fee transactions before lower-fee transactions. If blocks become full on a regular basis, users who pay a fee that's too small will have to wait a longer and longer time for their transactions to confirm. At this point, a demand-driven fee market may arise where transactions that pay higher fees get confirmed significantly faster than transactions that pay low fees.<ref name="todd_coinwallet">[https://gist.github.com/petertodd/8e87c782bdf342ef18fb Comments on the CoinWallet.eu tx-flood stress-test], Peter Todd, 22 June 2015</ref><ref name="garzik_bip" /><br />
<br />
In a competitive market, prices are driven by supply and demand and the emerging equilibrium price asymptotically approaches marginal costs over time. However, the current version of Bitcoin limits the supply to 1 MB per block, only allowing demand to adjust. To establish a free market, one would need to come up with a mechanism that allows the number of included transactions per block to adjust dynamically as well. The design of such a mechanism, however, is not trivial. Simply allowing individual miners to include as many transactions as they want is problematic due to the externalities<ref name="exernality">[https://en.wikipedia.org/wiki/Externality Definition of externality], Wikipedia, 26 January 2016</ref> of including additional blocks and explained further in section [[#Should miners be allowed to decide the block size?|'should miners be allowed to decide the block size?']] .<br />
<br />
=== What is the most efficient way to scale Bitcoin? ===<br />
<br />
Remove its decentralization properties, specifically decentralized mining and decentralized full nodes. Mining wastes enormous amounts of electricity to provide a decentralized ledger and full nodes waste an enormous amount of bandwidth and CPU time keeping miners honest.<br />
<br />
If users instead decided to hand authority over to someone they trusted, mining and keeping miners honest wouldn’t be needed. This is how Visa, MasterCard, PayPal, and the rest of the centralized payment systems works—users trust them, and they have no special difficulty scaling to [[scalability|millions of transactions an hour]]. It’s very efficient; it isn’t decentralized.<br />
<br />
=== What is a hard fork, and how does it differ from other types of forks? ===<br />
<br />
The word fork is badly overloaded in Bitcoin development.<br />
<br />
* '''[[hardfork|Hard fork]]:''' a change to the system which is not backwards compatible. Everyone needs to upgrade or things can go wrong.<br />
* '''[[softfork|Soft fork]]:''' a change to the system which is backwards compatible as long as a majority of miners enforce it. Full nodes that don’t upgrade have their security reduced.<br />
* '''Chain fork:''' when there are two are more blocks at the same height on a block chain. This typically happens a few times a week by accident, but it can also indicate more severe problems.<br />
* '''[https://en.wikipedia.org/wiki/Fork_%28software_development%29 Software fork]:''' using the code from an open source project to create a different project.<br />
* '''[https://help.github.com/articles/fork-a-repo/ Git/GitHub fork]:''' a way for developers to write and test new features before contributing them to a project.<br />
<br />
(There are other types of software-related forks, but they don’t tend to cause as much confusion.)<br />
<br />
=== What are the block size soft limits? ===<br />
<br />
Bitcoin Core has historically come pre-configured to limit blocks it mines to certain sizes.<ref name="fee_pri" /> These “limits” aren’t restrictions placed on miners by other miners or nodes, but rather configuration options that help miners produce reasonably-sized blocks.<br />
<br />
Miners can change their soft limit size (up to 1 MB) using <code>-blockmaxsize=&lt;size&gt;</code><br />
<br />
Default soft limits at various times:<br />
<br />
* '''July 2012:''' <code>-blockmaxsize</code> option created and set to default 250 KB soft limit<ref>[https://github.com/bitcoin/bitcoin/commit/c555400ca134991e39d5e3a565fcd2215abe56f6 Bitcoin Core commit c555400], Gavin Andresen, 12 July 2012</ref><br />
* '''November 2013:''' Raised to 750KB<ref>[https://github.com/bitcoin/bitcoin/commit/ad898b40aaf06c1cc7ac12e953805720fc9217c0 Bitcoin Core commit ad898b40], Gavin Andresen, 27 November 2013</ref><br />
* '''June 2015:''' Raise to 1 MB suggested<ref>[https://github.com/bitcoin/bitcoin/pull/6231 Bitcoin Core pull #6231], Chris Wheeler, 4 June 2015</ref><br />
<br />
== General Block Size Increase Theory ==<br />
<br />
Questions about increasing the block size in general, not related to any<br />
specific proposal.<br />
<br />
==== Why are some people in favor of keeping the block size at 1 MB forever? ====<br />
<br />
It is commonly claimed<ref name="garzik_bip" /><ref>[https://epicenterbitcoin.com/podcast/082/ Epicenter Bitcoin podcast #82], Mike Hearn (interviewed), 8 June 2015</ref> that there are people opposed to ever raising the maximum block size limit, but no Bitcoin developers have suggested keeping the maximum block size at one megabyte forever.<ref name="maxwell_not_proposing" /><br />
<br />
All developers support raising the maximum size at some point<ref>[https://www.reddit.com/r/Bitcoin/comments/39kqzs/how_about_a_softfork_optin_blocksize_increase/cs5hj8l Nothing magic about 1MB], Dr. Adam Back, 13 June 2015</ref><ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008328.html Regarding size-independent new block propagation], Pieter Wuille, 28 May 2015</ref>—they just disagree about whether now is the correct time.<br />
<br />
==== Should miners be allowed to decide the block size? ====<br />
<br />
A block may include as little as a single transaction, so miners can always restrict block size. Letting miners choose the maximum block size is more problematic for several reasons:<br />
<br />
# '''Miners profit, others pay the cost:''' bigger blocks earn miners more fees, but miners don’t need to store those blocks for more than a few days.<ref>[https://github.com/bitcoin/bitcoin/pull/5863 Bitcoin Core pull #5863 adding pruning functionality], Suhas Daftuar et al., 6 March 2015</ref> Other users who want full validation security, or who provide services to lightweight wallets, pay the costs of downloading and storing those larger blocks.<br />
# '''Bigger miners can afford more bandwidth:''' each miner needs to download every transaction that will be included in block,<ref name="maxwell_correcting_assumptions" /> which means that they all need to pay for high-speed connections. However, a miner with 8.3% of total hash rate can take that cost out of the about 300 BTC they make a day, while a miner with only 0.7% of total hash rate has to take that cost out of only 25 BTC a day. This means bigger miners may logically choose to make bigger blocks even though it may further centralize mining.<br />
# '''Centralized hardware production:''' only a few companies in the world produce efficient mining equipment, and many of them have chosen to stop selling to the public.<ref>[http://blogs.wsj.com/venturecapital/2014/09/05/for-kncminer-time-to-forget-selling-bitcoin-machines-to-at-home-miners/ KnCMiner to stop selling to home miners], Wall Street Journal, Yuliya Chernova, 5 September 2014</ref> This prevents ordinary Bitcoin users from participating in the process even if they were willing to pay for mining equipment.<br />
# '''Voting by hash rate favors larger miners:''' voting based on hash rate allows the current hash rate majority (or super-majority) to enforce conditions on the minority. This is similar to a lobby of large businesses being able to get laws passed that may hurt smaller businesses.<ref>[https://www.reddit.com/r/Bitcoin/comments/39kzyt/draft_bip_100_soft_fork_block_size_increase/cs5gvak Miners choosing the block size limit is ill-advised], Meni Rosenfeld, 13 June 2015</ref><br />
# '''Miners may not care about users:''' this was demonstrated during the [[July 2015 Forks]] where even after miners lost over $50,000 USD in income from mining invalid chains, and even after they were told that long forks harm users, they continued to mine improperly.<ref>[https://bitcointalk.org/index.php?topic=700411.msg11790734#msg11790734 Intention to continue SPV mining], Wang Chun, 4 July 2015</ref><br />
<br />
However, there are also possible justifications for letting miners choose the block size:<br />
<br />
# '''Authenticated participants:''' miners are active participants in Bitcoin, and they can prove it by adding data to the blocks they create.<ref>[https://bitcoin.org/en/developer-reference#term-coinbase-field Coinbase field], Bitcoin.org Developer Reference</ref> It is much harder to prove people on Reddit, BitcoinTalk, and elsewhere are real people with an active stake in Bitcoin.<br />
# '''Bigger blocks may cost miners:''' small miners and poorly-connected miners are at a disadvantage if larger blocks are produced<ref name="wuille_centralization" />, and even large and well-connected miners may find that large blocks reduce their profit percentage if the cost of bandwidth rises too high or their stale rate increases.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008355.html F2Pool block size concerns], Chun Wang, 29 May 2015</ref><br />
<br />
==== How could a block size increase affect user security? ====<br />
<br />
Bitcoin’s security is highly dependent on the number of active users who protect their bitcoins with a full node like Bitcoin Core. The more active users of full nodes, the harder it is for miners to trick users into accepting fake bitcoins or other frauds.<ref>[https://medium.com/@lopp/bitcoin-nodes-how-many-is-enough-9b8e8f6fd2cf Bitcoin nodes: how many is enough?], Jameson Lopp, 7 June 2015</ref><br />
<br />
Full nodes need to download and verify every block, and most nodes also store blocks plus relay transactions, full blocks, and filtered blocks to other users on the network. The bigger blocks become, the more difficult it becomes to do all this, so it is expected that bigger blocks will both reduce the number of users who currently run full nodes and suppress the number of users who decide to start running a full node later.<ref>[https://www.reddit.com/r/Bitcoin/comments/3bae2d/amir_taaki_on_raising_the_block_size_a_lot_of/cslcgmw Block size increases-only will create problems], Dr. Adam Back, 28 June 2015</ref><br />
<br />
In addition, full blocks may increase mining centralization<ref name="wuille_centralization" /> at a time when mining is already so centralized that it makes it easy to reverse transactions which have been confirmed multiple times.<ref>[http://bitcoin.stackexchange.com/questions/32562/when-to-worry-about-1-confirmation-payments/32564#32564 When to worry about one-confirmation payments], David A. Harding, 17 November 2014</ref><br />
<br />
==== How could larger blocks affect proof-of-work (POW) security? ====<br />
<br />
Proof of work security is dependent on how much money miners spend on mining equipment. However, to effectively mine blocks, miners also need to spend money on bandwidth to receive new transactions and blocks created by other miners; CPUs to validate received transactions and blocks; and bandwidth to upload new blocks. These additional costs don’t directly contribute to POW security.<ref name="maxwell_correcting_assumptions">[https://www.reddit.com/r/Bitcoin/comments/39tgno/letting_miners_vote_on_the_maximum_block_size_is/cs6rek5 Correcting wrong assumptions about mining], Gregory Maxwell, 15 June 2015</ref><br />
<br />
As block sizes increase, the amount of bandwidth and CPU required also increases. If block sizes increase faster than the costs of bandwidth and CPU decrease, miners will have less money for POW security relative to the gross income they earn.<br />
<br />
In addition, larger blocks have a higher risk of becoming stale (orphaned)<ref name="rusty_dsl" />, which directly correlates to lost POW security. For example, if the network average stale rate is 10%, then 10% of POW performed isn't protecting transactions on the block chain.<br />
<br />
=== What happens if blocks aren't big enough to include all pending transactions? ===<br />
<br />
This is already the case more often than not<ref>[http://statoshi.info/dashboard/db/transactions?from=1433297061121&to=1435889061123 Statoshi.info mempool queue June to July 2015]</ref>, so we know that miners will simply queue transactions. The transactions eligible for block inclusion that pay the highest fee per kilobyte will be confirmed earlier than transactions that pay comparatively lower fees.<ref name="fee_pri" /><br />
<br />
What happens from there is debated:<br />
<br />
* BitcoinJ lead developer Mike Hearn believes there would be “crashing nodes, a swelling transaction backlog, a sudden spike in double spending, [and] skyrocketing fees.”<ref>[https://medium.com/@octskyward/crash-landing-f5cc19908e32 Crash Landing], Mike Hearn, 7 May 2015</ref><br />
* Bitcoin Foundation chief scientist Gavin Andresen believes that the “average transaction fee paid will rise, people or applications unwilling or unable to pay the rising fees will stop submitting transactions, [and] people and businesses will shelve plans to use Bitcoin, stunting growth and adoption.” <ref>[https://github.com/bitcoin/bitcoin/pull/6341 Bitcoin Core pull #6341], Gavin Andresen, 26 June 2015</ref><br />
* Bitcoin Core developer Pieter Wuille replies to Andresen’s comment above: “Is it fair to summarize this as ‘Some use cases won’t fit any more, people will decide to no longer use the blockchain for these purposes, and the fees will adapt.’? I think that is already happening […] I don’t think we should be afraid of this change or try to stop it.” <ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009098.html The need for larger blocks], Pieter Wuille, 26 June 2015</ref><br />
* Bitcoin Core developer Jeff Garzik writes, "as blocks get full and the bidding war ensues, the bitcoin user experience rapidly degrades to poor. In part due to bitcoin wallet software’s relative immaturity, and in part due to bitcoin’s settlement based design, the end user experience of their transaction competing for block size results in erratic, and unpredictably extended validation times."<ref name="garzik_bip" /><br />
<br />
== Specific Scaling Proposals ==<br />
<br />
=== Andresen-Hearn Block Size Increase Proposals ===<br />
<br />
Questions about the series of related proposals by Gavin Andresen and Mike Hearn to use a hard fork to raise the maximum block size, thereby allowing miners to include more on-chain transactions. As of July 2015, the current focus is [https://github.com/bitcoin/bips/pull/163 BIP101].<br />
<br />
==== What is the major advantage of this proposal? ====<br />
<br />
''Bitcoin can support many more users.'' Assuming earliest possible adoption, 250 bytes per on-chain transaction, 144 blocks per day, and 2 transaction a day per user, Bitcoin can support about,<br />
<br />
* 288,000 users in 2015<br />
* 2,304,000 users in 2016 (800% increase)<br />
* 4,608,000 in 2018 (1,600%)<br />
* 9,216,000 in 2020 (3,200%)<br />
* 18,432,000 in 2022 (6,400%)<br />
* 36,864,000 in 2024 (12,800%)<br />
* 73,728,000 in 2026 (25,600%)<br />
* 147,456,000 in 2028 (51,200%)<br />
* 294,912,000 in 2030 (102,400%)<br />
* 589,824,000 in 2032 (204,800%)<br />
* 1,179,648,000 in 2034 (409,600%<br />
* 2,359,296,000 in 2036 (819,200%)<br />
<br />
==== What is the major disadvantage of this proposal? ====<br />
<br />
''The total cost of remaining decentralized will be high.'' Assuming earliest possible adoption and that the ratio of total users to full node operators remains the same as today, the total estimated amount of work necessary to maintain the decentralized system under the [[#O.28n2.29_network_total_validation_resource_requirements|O(<sup>2</sup>) scaling model]] will be,<br />
<br />
* 100% of today’s work in 2015<br />
* 6,400% in 2016<br />
* 25,600% in 2018<br />
* 102,400% in 2020<br />
* 409,600% in 2022<br />
* 1,638,400% in 2024<br />
* 6,553,600% in 2026<br />
* 26,214,400% in 2028<br />
* 104,857,600% in 2030<br />
* 419,430,400% in 2032<br />
* 1,677,721,600% in 2034<br />
* 6,710,886,400% in 2036<br />
<br />
For example, if the total amount spent on running full nodes today (not counting mining) is $100 thousand per year, the estimated cost for the same level of decentralization in 2036 will be $6.7 trillion per year if validation costs stay the same. (They'll certainly go down, but algorithmic and hardware improvements probably won't eliminate an approximate 6,710,886,400% cost increase.)<br />
<br />
==== What are the dangers of the proposed hard fork? ====<br />
<br />
Under the current proposal, 75% of miners must indicate that they agree to accept blocks up to 8 MB in size.<ref name="bip101">[https://github.com/bitcoin/bips/pull/163 BIP101], Gavin Andresen, 24 June 2016</ref> After the change goes into effect, if any miner creates a block larger than 1 MB, all nodes which have not upgraded yet will reject the block.<ref>[https://bitcoin.org/en/developer-guide#consensus-rule-changes Consensus rule changes], Bitcoin.org Developer Guide</ref><br />
<br />
If all full nodes have upgraded, or very close to all nodes, there should be no practical effect. If a significant number of full nodes have not upgraded, they will continue using a different block chain than the upgraded users, with the following consequences:<br />
<br />
* Bitcoins received from before the fork can be spent twice, once on both sides of the fork. This creates a high double spend risk.<br />
* Bitcoins received after the fork are only guaranteed to be spendable on the side of the fork they were received on. This means some users will have to lose money to restore Bitcoin to a single chain.<br />
<br />
Users of hosted wallets (Coinbase, BlockChain.info, etc.) will use whatever block chain their host chooses. Users of lightweight P2P SPV wallets will use the [[Thin Client Security|longest chain they know of]], which may not be the actual longest chain if they only connect to nodes on the shorter chain. Users of non-P2P SPV wallets, like Electrum, will use whatever chain is used by the server they connect to.<br />
<br />
If a bad hard fork like this happens, it will likely cause large-scale confusion and make Bitcoin very hard to use until the situation is resolved.<br />
<br />
==== What is the deployment schedule for BIP 101? ====<br />
<br />
* The patch needs to be accepted into Bitcoin Core, Bitcoin XT, or both.<br />
* If accepted into Bitcoin Core, miners using that software will need to upgrade (this probably requires a new released version of Bitcoin Core). If accepted only into Bitcoin XT, miners will need to switch to using XT.<br />
* After 75% of miners have upgraded, 8MB blocks will become allowed at the the latest of (1) 11 January 2016 or (2) two weeks after the 75% upgrade threshold.<ref name="bip101" /><br />
* After the effective date has passed, any miner may create a block larger than 8MB. When a miner does this, upgraded full nodes will accept that block and non-upgraded full nodes will reject it, forking the network.<ref name="bip101" /> See [[#What_are_the_dangers_of_the_proposed_hard_fork.3F|hard fork dangers]] for what his might mean.<br />
<br />
==== Will miners go straight from 1 MB blocks to 8 MB blocks? ====<br />
<br />
That would be highly unlikely. Uploading an 8 MB block currently takes significantly more time than uploading a 1 MB block<ref name="rusty_dsl">[http://rusty.ozlabs.org/?p=509 Mining on a home DSL connection test results], Rusty Russell, 19 June 2015</ref>, even with the roughly 25x reduction in size available from use of Matt Corallo’s block relay network.<ref name="block_relay_net" /><br />
<br />
The longer it takes to upload a block, the higher the risk it will become a stale block—meaning the miner who created it will not receive the block subsidy or transaction fees (currently about 25 BTC per block).<br />
<br />
However, if technology like Invertible Bloom Lookup Tables (IBLTs) is deployed and found to work as expected<ref name="iblt">[https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2 O(1) block propagation], Gavin Andresen, 8 August 2014</ref>, or if mining [[#What_is_the_most_efficient_way_to_scale_Bitcoin.3F|centralizes further]], adding additional transactions may not have a significant enough cost to discourage miners from creating full blocks. In that case, blocks will be filled as soon as there are enough people wanting to make transactions paying the default relay fee<ref>[https://github.com/bitcoin/bitcoin/pull/3305 Bitcoin Core pull #3305 dropping default fees], Mike Hearn, 22 November 2013</ref> of 0.00001000 BTC/kilobyte.<br />
<br />
==== What tests have been performed related to this proposal? ====<br />
<br />
* '''20MB block processing''' (Gavin Andresen) “if we increased the maximum block size to 20 megabytes tomorrow, and every single miner decided to start creating 20MB blocks and there was a sudden increase in the number of transactions on the network to fill up those blocks… the 0.10.0 version of [Bitcoin Core] would run just fine.”<ref>[http://gavintech.blogspot.com/2015/01/twenty-megabytes-testing-results.html Twenty megabyte block testing], Gavin Andresen, 20 January 2015</ref> (ellipses in original)<br />
* '''Mining &amp; relay simulation''' (Gavin Andresen) “if blocks take 20 seconds to propagate, a network with a miner that has 30% of the hashing power will get 30.3% of the blocks.”<ref>[http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners Are bigger blocks better for bigger miners?], Gavin Andresen, 22 May 2015</ref><br />
* '''Mining on a home DSL connection''' (Rusty Russell) “Using the rough formula of 1-exp(-t/600), I would expect orphan rates of 10.5% generating 1MB blocks, and 56.6% with 8MB blocks; that’s a huge cut in expected profits.”<ref name="rusty_dsl" /><br />
* '''Mining centralization pressure''' (Pieter Wuille) “[This] does very clearly show the effects of larger blocks on centralization pressure of the system.”<ref name="wuille_centralization">[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008581.html Mining centralization pressure from non-uniform propagation speed], Pieter Wuille, 12 June 2015</ref><br />
<br />
<br />
=== Garzik Miner Block Size Voting Proposal (AKA BIP100) ===<br />
<br />
''Note, BIP 100 is the marketing name for this proposal. No BIP number<br />
has yet been publicly requested, and the number assigned is unlikely to<br />
be 100.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-May/005756.html<br />
Prenumbered BIP naming], Gregory Maxwell, 12 May 2014</ref>''<br />
<br />
Questions related to Jeff Garzik's proposal<ref name="garzik_bip">[http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf Draft BIP: decentralized economic policy], Jeff Garzik, 12 June 2015 (revised 15 June 2015)</ref> to allow miners to vote on raising and lowering the maximum block size.<br />
<br />
==== What does this proposal do? ====<br />
<br />
# It creates a one-time hard fork that does not automatically change the maximum block size.<br />
<br />
# It allows miners to vote to increase or decrease the maximum block size within the range of 1MB to 32MB. These changes are neither hard forks nor soft forks, but simply rules that all nodes should know about after the initial hard fork.<br />
<br />
==== Does it reduce the risk of a hard fork? ====<br />
<br />
Hard forks are most dangerous when they're done without strong<br />
consensus.<ref name="garzik_bip" /><ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008779.html Consensus changes are not about making a change to the software],<br />
Pieter Wuille, 18 June 2015</ref><br />
<br />
If Garzik's proposal gains strong consensus, it will be as safe as possible<br />
for a hard fork and it will allow increasing the block size up to 32 MB<br />
without any additional risk of a fork.<br />
<br />
==== Why is it limited to 32 megabytes? ====<br />
<br />
According to the draft BIP, "the 32 MB hard fork is largely coincidental -- a whole network upgrade at 32 MB was likely needed anyway."<br />
<br />
=== Lightning Network ===<br />
<br />
Questions related to using the proposed [http://lightning.network/ Lightning network] as a way to scale the number of users Bitcoin can support.<br />
<br />
==== How does transaction security differ from that of Bitcoin? ====<br />
<br />
Transactions on the proposed Lightning network use Bitcoin transactions exclusively to transfer bitcoins<ref name="russell_lightning1">[http://rusty.ozlabs.org/?p=450 Lightning Networks: Part I], Rusty Russell, 30 March 2015</ref>, and so the same security as regular Bitcoin transactions is provided when both a Lightning hub and client are cooperating.<br />
<br />
When a Lightning hub or client refuses to cooperate with the other (maybe because they accidentally went offline), the other party can still receive their full 100% bitcoin balance by closing the payment channel—but they must first wait for a defined amount of time mutually chosen by both the hub and client.<ref>[http://rusty.ozlabs.org/?p=462 Lightning Networks: Part II], Rusty Russell, 1 April 2015</ref><br />
<br />
If one party waits too long to close the payment channel, the other party may be able to steal bitcoins. However, it is possible to delegate the task of closing the channel in an emergency to an unlimited number of hubs around the Internet, so closing the channel on time should be easy.<ref name="russell_lightning4">[http://rusty.ozlabs.org/?p=477 Lightning Networks: Part IV], Rusty Russell, 8 April 2015</ref><br />
<br />
In summary, provided that payment channels are closed on time, the worst that can happen to users is that they may have to wait a few weeks for a channel to fully close before spending the bitcoins they received from it. Their security is otherwise the same as with regular Bitcoin.<br />
<br />
For Lightning hubs, security is slightly worse in the sense that they need to keep a potentially-large amount of funds in a hot wallet<ref name="lightning_paper">[http://lightning.network/lightning-network-paper-DRAFT-0.5.pdf Lightning Network (Draft 0.5)], Section 6.3: Coin Theft via Hacking, Joseph Poon and Thaddeus Dryja</ref>, so they can’t take advantage of the anti-hacking protection offered by cold wallets. Otherwise, Lightning hubs have the same security as clients.<br />
<br />
==== When will Lightning be ready for use? ====<br />
<br />
Lightning requires a basic test implementation (work underway<ref>[https://lists.blockstream.com/pipermail/lightning-dev/2015-June/000018.html Lightning first steps], Rusty Russell, 13 June 2015</ref>), several soft-fork changes to the Bitcoin protocol (work underway<ref>[https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65: CheckLockTimeVerify], Peter Todd, 1 October 2014</ref><ref>[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68: Consensus-enforced transaction replacement], Mark Friedenbach, 28 May 2015</ref>, and wallets need to be updated to support the Lightning network protocol.<ref name="russell_lightning4" /><br />
<br />
Dr. Adam Back has said, "I expect we can get something running inside a year."<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009242.html Reply to Andresen regarding Lightning], Dr. Adam Back, 28 June 2015</ref><br />
<br />
==== Doesn’t Lightning require bigger blocks anyway? ====<br />
<br />
Lightning is block-size neutral. It requires one on-chain transaction to open a channel between a hub and a client, and one on-chain transaction to close a channel.<ref name="russell_lightning1" /> In between it can support an unlimited number of transactions between anyone on the Lightning network.<ref name="lightning_paper" /><br />
<br />
Using the numbers from the Lightning presentation<ref name="lightning_slides">[http://lightning.network/lightning-network.pdf Lightning presentation], Joseph Poon, 23 February 2015</ref>, if people open and close a plausible two channels a year, Lightning can support about 52 million users with the current one-megabyte limit—and each user can make an unlimited number of transactions. Currently, assuming people make an average of only two Bitcoin transactions a day, basic Bitcoin can support only 288,000 users.<br />
<br />
Under these assumptions, Lightning is 180 times (17,900%) more efficient than basic Bitcoin.<br />
<br />
Presumably, if around 30 million people are using Bitcoin via Lightning so that capacity is called into question, it will not be difficult to find consensus to double the block size to two megabytes and bring user capacity up to 105 million. The same goes for later increases to 200 million (4MB), 400 million (8MB), 800 million (16MB), 1.6 billion (32 MB), 3.2 billion (64MB), and all 7 billion living humans (133MB). In each case, all Lightning network participants get unlimited transactions to the other participants.<br />
<br />
For basic Bitcoin to scale to just 2 transactions a day for 7 billion people would require 24-gigabyte blocks.<ref name="lightning_slides" /><br />
<br />
=== Sidechains ===<br />
<br />
==== Real quick, what are sidechains? ====<br />
<br />
Block chains that are separate from Bitcoin’s block chain, but which allow you to receive and spend bitcoins using a two-way peg (2WP).<ref name="sidechains_paper">[https://www.blockstream.com/sidechains.pdf Sidechains paper], Adam Back et al., 22 October 2014</ref> (Although a sidechain can never be more secure than the Bitcoin block chain.<ref>[https://www.reddit.com/r/Bitcoin/comments/39r85g/sidechain_hate/cs5spbg Security limitations of pegged chains], Gregory Maxwell, 14 June 2015</ref>)<br />
<br />
==== Are sidechains a scaling option? ====<br />
<br />
No. Sidechains have the same fundamental scaling problems as Bitcoin does. Moving some transactions to sidechains simply moves some problems elsewhere on the network—the total difficulty of the problem remains the same.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008617.html Sidechains not a direct means for solving any of the scaling problems Bitcoin has], Pieter Wuille, 13 June 2015</ref><br />
<br />
==== But couldn’t I create a sidechain that had 100 GB blocks? ====<br />
<br />
Certainly, sidechain code is open source<ref>[https://github.com/ElementsProject/elements Elements Project]</ref>—so you can create your own sidechain. But you’d still have the difficulty of finding people who are willing to validate 100 GB blocks with their own full nodes.<br />
<br />
==== Do sidechains require a hard fork? ====<br />
<br />
No. Federated sidechains, such as have already been implemented<ref>[https://github.com/ElementsProject/elements/tree/alpha Elements Alpha]</ref>, don’t require any changes to the Bitcoin consensus rules. Merged-mined sidechains, which have not been implemented yet, do require a backwards-compatible soft fork in order to transfer funds between Bitcoin and the sidechain.<ref name="sidechains_paper" /><br />
<br />
== References ==<br />
<references /></div>Amincdhttps://en.bitcoin.it/w/index.php?title=Scalability_FAQ&diff=60389Scalability FAQ2016-02-14T15:37:17Z<p>Amincd: /* What is the short history of the block size limit? */</p>
<hr />
<div>Answers to commonly-asked questions and concerns about scaling Bitcoin, including “level 1” solutions such as increasing the block size and “level 2” solutions such as the proposed Lightning network.<br />
<br />
== Background ==<br />
<br />
Questions about how Bitcoin currently works (related to scaling) as well as questions about the technical terminology related to the scaling discussion.<br />
<br />
=== What is the short history of the block size limit? ===<br />
<br />
''Note: the software now called Bitcoin Core was previously simply called “Bitcoin”.<ref>[https://bitcoin.org/en/release/v0.9.0#rebranding-to-bitcoin-core Bitcoin Core 0.9.0 release notes], Bitcoin.org, 19 March 2014</ref> To avoid confusion with the Bitcoin system, we’ll use the Bitcoin Core name.''<br />
<br />
Bitcoin Core was initially released without an explicit block size limit. However, the code did limit network messages to a maximum of 32 MiB, setting an effective upper bound on block size.<ref>[https://bitcointalk.org/index.php?topic=68121 Earliest known Bitcoin code], <code>src/main.h:17</code></ref><br />
<br />
Around 15 July 2010, Satoshi Nakamoto changed Bitcoin Core’s mining code so that it wouldn’t create any blocks larger than 990,000 bytes.<ref>[https://github.com/bitcoin/bitcoin/commit/a30b56ebe76ffff9f9cc8a6667186179413c6349 Bitcoin Core commit a30b56e], Satoshi Nakamoto, 15 July 2010</ref><br />
<br />
Two months later on 7 September 2010, Nakamoto changed Bitcoin Core’s consensus rules to reject blocks larger than 1,000,000 bytes (1 megabyte) if their block height was higher than 79,400.<ref>[https://github.com/bitcoin/bitcoin/commit/8c9479c6bbbc38b897dc97de9d04e4d5a5a36730 Bitcoin Core commit 8c9479c], Satoshi Nakamoto, 7 September 2010</ref> (Block 79,400 was later produced on 12 September 2010.<ref>[https://www.biteasy.com/blockchain/blocks/000000000021d821ec06be7173f413690bc5c4bc648dfa70b3b6763236f055b7 Block height 79400], dated 12 September 2010</ref>)<br />
<br />
Neither the July nor the September commit message explains the reason for the limit, although the careful attempt to prevent a fork may indicate Nakamoto didn’t consider it an emergency.<br />
<br />
Nakamoto’s subsequent statements supported raising the block size at a later time<ref>[https://bitcointalk.org/index.php?topic=1347.msg15139#msg15139 Increasing the block size when needed], Satoshi Nakamoto, 3 October 2010</ref>, but he never publicly specified a date or set of conditions for the raise.<br />
<br />
Statements by Nakamoto in the summer of 2010 indicate he believed Bitcoin could scale to block sizes far larger 1 megabyte. For example, on 5 August 2010, he wrote that "[W]hatever size micropayments you need will eventually be practical. I think in 5 or 10 years, the bandwidth and storage will seem trivial" and "[microtransactions on the blockchain] can become more practical ... if I implement client-only mode and the number of network nodes consolidates into a smaller number of professional server farms" <ref>[https://bitcointalk.org/index.php?topic=532.msg6306#msg6306 the number of network nodes consolidates into a smaller number of professional server farms]</ref>. <br />
<br />
These statements suggest that the intended purpose of the 1 megabyte limit was not to keep bandwidth and storage requirements for running a Bitcoin node low enough to be practical for personal computers and consumer-grade internet connections, and that the limit would be lifted to accommodate greater demand for transactional capacity.<br />
<br />
=== What is this Transactions Per Second (TPS) limit? ===<br />
<br />
The current block size limit is 1,000,000 bytes (1 megabyte)<ref>[https://github.com/bitcoin/bitcoin/blob/41076aad0cbdfa4c4cf376e345114a5c29086f81/src/consensus/consensus.h#L10 <code>MAX_BLOCK_SIZE</code>], retrieved 2 July 2015</ref>, although a small amount of that space (such as the block header) is not available to store transactions.<ref>[https://bitcoin.org/en/developer-reference#serialized-blocks Block serialization description], Bitcoin.org Developer Reference</ref><br />
<br />
Bitcoin transactions vary in size depending on multiple factors, such as whether they’re spending single-signature inputs or a multiple signature inputs, and how many inputs and outputs they have.<br />
<br />
The simple way to calculate the number of Transactions Per Second (TPS) Bitcoin can handle is to divide the block size limit by the expected average size of transactions, divided by the average number of seconds between blocks (600). For example, if you assume average transactions are 250 bytes,<br />
<br />
<pre>6.6 TPS = 1,000,000 / 250 / 600</pre><br />
<br />
There seems to be general agreement that Bitcoin in 2015 can handle about 3 TPS with the current average size of transactions.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/007986.html Max TPS based on current average transaction size], Mike Hearn, 8 May 2015</ref><ref name="maxwell_not_proposing">[https://www.reddit.com/r/Bitcoin/comments/39yaod/bitcoinorg_position_on_hard_forks/cs7qz5c "No one proposing 3 TPS forever"], Gregory Maxwell, 15 June 2015</ref><br />
<br />
Both old estimates<ref>[[Scalability]], Bitcoin Wiki, retrieved 7 July<br />
2015</ref> and new estimates<ref name="garzik_bip" /> place the<br />
theoretical maximum at 7 TPS with current Bitcoin consensus rules<br />
(including the 1MB block size limit).<br />
<br />
=== What do devs mean by the scaling expressions O(1), O(n), O(n<sup>2</sup>), etc…? ===<br />
<br />
[https://en.wikipedia.org/wiki/Big_O_notation Big O notation] is a shorthand used by computer scientists to describe how well a system scales. Such descriptions are rough approximations meant to help predict potential problems and evaluate potential solutions; they are not usually expected to fully capture all variables.<br />
<br />
* '''O(1)''' means a system has roughly the same properties no matter how big it gets.<br />
* '''O(n)''' means that a system scales linearly: doubling the number of things (users, transactions, etc.) doubles the amount of work.<br />
* '''O(n<sup>2</sup>)''' means that a system scales quadratically : doubling (2x) the number of things quadruples (4x) the amount of work. Often written O(n^2) is places without convenient superscripts.<br />
* Additional examples may be found in the [https://en.wikipedia.org/wiki/Big_O_notation#Orders_of_common_functions Wikipedia article]<br />
<br />
The following subsections show cases where big O notation has been applied to the scaling Bitcoin transaction volume.<br />
<br />
==== O(1) block propagation ====<br />
<br />
Bitcoin Core currently relays unconfirmed transactions and then later relays blocks containing many of the same transactions. This redundant relay can be eliminated to allow miners to propagate large blocks very quickly to active network nodes, and would also significantly reduce miner need for peak bandwidth. Currently most miners use a network<ref name="block_relay_net">[http://bitcoinrelaynetwork.org/ Matt Corallo's block relay network]</ref> that is about 25x more efficient than stock Bitcoin Core<ref>[https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2#i-know-that-you-know IBLT design document], Gavin Andresen, 11 August 2014</ref> and almost equally as effective as O(1) block propagation for current block sizes.<br />
<br />
==== O(n<sup>2</sup>) network total validation resource requirements ====<br />
<br />
[[File:On2_scaling_illustrated.png|thumb|right|visualization of O(n<sup>2</sup>) scaling]]<br />
<br />
Each on-chain Bitcoin transaction needs to be processed by each full node. If we assume that a certain percentage of users run full nodes (''n'') and that each user creates a certain number of transactions on average (''n'' again), then the network’s total resource requirements are <code>n<sup>2</sup> = n * n</code>. In short, this means that the aggregate cost of keeping all transactions on-chain quadruples each time the number of users doubles.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009199.html Total system cost], Dr. Adam Back, 28 June 2015</ref> For example,<br />
<br />
* Imagine a network starts with 100 users and 2 total nodes (a 2% ratio).<br />
* The network doubles in users to 200. The number of nodes also doubles to 4 (maintaining a 2% ratio of decentralized low-trust security). However, double the number of users means double the number of transactions, and each node needs to process ''every'' transaction---so each node now does double work with its bandwidth and its CPU. With double the number of nodes and double the amount of work per node, total work increases by four times.<br />
* The network doubles again: 400 users, 8 nodes (still 2% of total), and 4 times the original workload per node for a total of 16 times as much aggregate work as the original.<br />
* Another doubling: 800 users, 16 nodes (still 2%), and 8 times the original workload per node for a total of 64 times aggregate work as the original.<br />
* Another doubling: 1,600 users—sixteen times the original---with 32 nodes (still 2%), and 16 times the original workload per node. The aggregate total work done by nodes is 256 times higher than it was originally.<br />
<br />
Note that the validation effort required per full node simply grows in O(n). For a single node, it takes twice as many resources to process twice as many transactions.<br />
<br />
=== What’s the difference between on-chain and off-chain transactions? ===<br />
<br />
On-chain Bitcoin transactions are those that appear in the Bitcoin block chain. Off-chain transactions are those that transfer ownership of bitcoins without putting a transaction on the block chain.<br />
<br />
Common and proposed off-chain transactions include:<br />
<br />
* '''Exchange transactions:''' when you buy or sell bitcoins, the exchange tracks ownership in a database without putting data in the block chain. Only when you deposit or withdraw bitcoins does the transaction appear on the block chain.<br />
* '''Web wallet internal payments:''' many web wallets allow users of the service to pay other users of the same service using off-chain payments. For example, when one Coinbase user pays another Coinbase user.<br />
* '''Tipping services:''' most tipping services today, such as ChangeTip, use off-chain transactions for everything except deposits and withdrawals.<ref>[https://www.changetip.com/fees ChangeTip fees], retrieved 3 July 2015</ref><br />
* '''Payment channels:''' channels are started using one on-chain transaction and ended using a second on-chain transaction.<ref>[https://bitcoin.org/en/developer-guide#micropayment-channel Micropayment channels], Bitcoin.org Developer Guide</ref> In between can be an essentially unlimited number of off-chain transactions as small as a single satoshi (1/100,000,000th of a bitcoin). Payment channels include those that [https://bitcoinj.github.io/working-with-micropayments exist today] as well as proposed hub-and-spoke channels and the more advanced [http://lightning.network/ Lightning network].<br />
<br />
Approximately 90% to 99% of all bitcoin-denominated payments today are made off-chain.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008844.html Pure off-chain is a weak form of layer 2], Dr. Adam Back, 19 June 2015</ref><br />
<br />
=== What is a fee market? ===<br />
<br />
When you create a Bitcoin transaction, you have the option to pay a [[transaction fee]]. If your software is flexible, you can pay anything from zero fees (a free transaction) to 100% of the value of the transaction (spend-to-fees). This fee is comparable to a tip. The higher it is, the bigger the incentive of the miners to incorporate your transaction into the next block.<br />
<br />
When miners assemble a block, they are free to include whatever transactions they wish. They usually include as many as possible up to the maximum block size and then prioritize the transactions that pay the most fees per kilobyte of data.<ref name="fee_pri">[https://bitcointalk.org/index.php?topic=95837.0 Fee prioritization patch], Gavin Andresen, 26 July 2012</ref> This confirms higher-fee transactions before lower-fee transactions. If blocks become full on a regular basis, users who pay a fee that's too small will have to wait a longer and longer time for their transactions to confirm. At this point, a demand-driven fee market may arise where transactions that pay higher fees get confirmed significantly faster than transactions that pay low fees.<ref name="todd_coinwallet">[https://gist.github.com/petertodd/8e87c782bdf342ef18fb Comments on the CoinWallet.eu tx-flood stress-test], Peter Todd, 22 June 2015</ref><ref name="garzik_bip" /><br />
<br />
In a competitive market, prices are driven by supply and demand and the emerging equilibrium price asymptotically approaches marginal costs over time. However, the current version of Bitcoin limits the supply to 1 MB per block, only allowing demand to adjust. To establish a free market, one would need to come up with a mechanism that allows the number of included transactions per block to adjust dynamically as well. The design of such a mechanism, however, is not trivial. Simply allowing individual miners to include as many transactions as they want is problematic due to the externalities<ref name="exernality">[https://en.wikipedia.org/wiki/Externality Definition of externality], Wikipedia, 26 January 2016</ref> of including additional blocks and explained further in section [[#Should miners be allowed to decide the block size?|'should miners be allowed to decide the block size?']] .<br />
<br />
=== What is the most efficient way to scale Bitcoin? ===<br />
<br />
Remove its decentralization properties, specifically decentralized mining and decentralized full nodes. Mining wastes enormous amounts of electricity to provide a decentralized ledger and full nodes waste an enormous amount of bandwidth and CPU time keeping miners honest.<br />
<br />
If users instead decided to hand authority over to someone they trusted, mining and keeping miners honest wouldn’t be needed. This is how Visa, MasterCard, PayPal, and the rest of the centralized payment systems works—users trust them, and they have no special difficulty scaling to [[scalability|millions of transactions an hour]]. It’s very efficient; it isn’t decentralized.<br />
<br />
=== What is a hard fork, and how does it differ from other types of forks? ===<br />
<br />
The word fork is badly overloaded in Bitcoin development.<br />
<br />
* '''[[hardfork|Hard fork]]:''' a change to the system which is not backwards compatible. Everyone needs to upgrade or things can go wrong.<br />
* '''[[softfork|Soft fork]]:''' a change to the system which is backwards compatible as long as a majority of miners enforce it. Full nodes that don’t upgrade have their security reduced.<br />
* '''Chain fork:''' when there are two are more blocks at the same height on a block chain. This typically happens a few times a week by accident, but it can also indicate more severe problems.<br />
* '''[https://en.wikipedia.org/wiki/Fork_%28software_development%29 Software fork]:''' using the code from an open source project to create a different project.<br />
* '''[https://help.github.com/articles/fork-a-repo/ Git/GitHub fork]:''' a way for developers to write and test new features before contributing them to a project.<br />
<br />
(There are other types of software-related forks, but they don’t tend to cause as much confusion.)<br />
<br />
=== What are the block size soft limits? ===<br />
<br />
Bitcoin Core has historically come pre-configured to limit blocks it mines to certain sizes.<ref name="fee_pri" /> These “limits” aren’t restrictions placed on miners by other miners or nodes, but rather configuration options that help miners produce reasonably-sized blocks.<br />
<br />
Miners can change their soft limit size (up to 1 MB) using <code>-blockmaxsize=&lt;size&gt;</code><br />
<br />
Default soft limits at various times:<br />
<br />
* '''July 2012:''' <code>-blockmaxsize</code> option created and set to default 250 KB soft limit<ref>[https://github.com/bitcoin/bitcoin/commit/c555400ca134991e39d5e3a565fcd2215abe56f6 Bitcoin Core commit c555400], Gavin Andresen, 12 July 2012</ref><br />
* '''November 2013:''' Raised to 750KB<ref>[https://github.com/bitcoin/bitcoin/commit/ad898b40aaf06c1cc7ac12e953805720fc9217c0 Bitcoin Core commit ad898b40], Gavin Andresen, 27 November 2013</ref><br />
* '''June 2015:''' Raise to 1 MB suggested<ref>[https://github.com/bitcoin/bitcoin/pull/6231 Bitcoin Core pull #6231], Chris Wheeler, 4 June 2015</ref><br />
<br />
== General Block Size Increase Theory ==<br />
<br />
Questions about increasing the block size in general, not related to any<br />
specific proposal.<br />
<br />
==== Why are some people in favor of keeping the block size at 1 MB forever? ====<br />
<br />
It is commonly claimed<ref name="garzik_bip" /><ref>[https://epicenterbitcoin.com/podcast/082/ Epicenter Bitcoin podcast #82], Mike Hearn (interviewed), 8 June 2015</ref> that there are people opposed to ever raising the maximum block size limit, but no Bitcoin developers have suggested keeping the maximum block size at one megabyte forever.<ref name="maxwell_not_proposing" /><br />
<br />
All developers support raising the maximum size at some point<ref>[https://www.reddit.com/r/Bitcoin/comments/39kqzs/how_about_a_softfork_optin_blocksize_increase/cs5hj8l Nothing magic about 1MB], Dr. Adam Back, 13 June 2015</ref><ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008328.html Regarding size-independent new block propagation], Pieter Wuille, 28 May 2015</ref>—they just disagree about whether now is the correct time.<br />
<br />
==== Should miners be allowed to decide the block size? ====<br />
<br />
A block may include as little as a single transaction, so miners can always restrict block size. Letting miners choose the maximum block size is more problematic for several reasons:<br />
<br />
# '''Miners profit, others pay the cost:''' bigger blocks earn miners more fees, but miners don’t need to store those blocks for more than a few days.<ref>[https://github.com/bitcoin/bitcoin/pull/5863 Bitcoin Core pull #5863 adding pruning functionality], Suhas Daftuar et al., 6 March 2015</ref> Other users who want full validation security, or who provide services to lightweight wallets, pay the costs of downloading and storing those larger blocks.<br />
# '''Bigger miners can afford more bandwidth:''' each miner needs to download every transaction that will be included in block,<ref name="maxwell_correcting_assumptions" /> which means that they all need to pay for high-speed connections. However, a miner with 8.3% of total hash rate can take that cost out of the about 300 BTC they make a day, while a miner with only 0.7% of total hash rate has to take that cost out of only 25 BTC a day. This means bigger miners may logically choose to make bigger blocks even though it may further centralize mining.<br />
# '''Centralized hardware production:''' only a few companies in the world produce efficient mining equipment, and many of them have chosen to stop selling to the public.<ref>[http://blogs.wsj.com/venturecapital/2014/09/05/for-kncminer-time-to-forget-selling-bitcoin-machines-to-at-home-miners/ KnCMiner to stop selling to home miners], Wall Street Journal, Yuliya Chernova, 5 September 2014</ref> This prevents ordinary Bitcoin users from participating in the process even if they were willing to pay for mining equipment.<br />
# '''Voting by hash rate favors larger miners:''' voting based on hash rate allows the current hash rate majority (or super-majority) to enforce conditions on the minority. This is similar to a lobby of large businesses being able to get laws passed that may hurt smaller businesses.<ref>[https://www.reddit.com/r/Bitcoin/comments/39kzyt/draft_bip_100_soft_fork_block_size_increase/cs5gvak Miners choosing the block size limit is ill-advised], Meni Rosenfeld, 13 June 2015</ref><br />
# '''Miners may not care about users:''' this was demonstrated during the [[July 2015 Forks]] where even after miners lost over $50,000 USD in income from mining invalid chains, and even after they were told that long forks harm users, they continued to mine improperly.<ref>[https://bitcointalk.org/index.php?topic=700411.msg11790734#msg11790734 Intention to continue SPV mining], Wang Chun, 4 July 2015</ref><br />
<br />
However, there are also possible justifications for letting miners choose the block size:<br />
<br />
# '''Authenticated participants:''' miners are active participants in Bitcoin, and they can prove it by adding data to the blocks they create.<ref>[https://bitcoin.org/en/developer-reference#term-coinbase-field Coinbase field], Bitcoin.org Developer Reference</ref> It is much harder to prove people on Reddit, BitcoinTalk, and elsewhere are real people with an active stake in Bitcoin.<br />
# '''Bigger blocks may cost miners:''' small miners and poorly-connected miners are at a disadvantage if larger blocks are produced<ref name="wuille_centralization" />, and even large and well-connected miners may find that large blocks reduce their profit percentage if the cost of bandwidth rises too high or their stale rate increases.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008355.html F2Pool block size concerns], Chun Wang, 29 May 2015</ref><br />
<br />
==== How could a block size increase affect user security? ====<br />
<br />
Bitcoin’s security is highly dependent on the number of active users who protect their bitcoins with a full node like Bitcoin Core. The more active users of full nodes, the harder it is for miners to trick users into accepting fake bitcoins or other frauds.<ref>[https://medium.com/@lopp/bitcoin-nodes-how-many-is-enough-9b8e8f6fd2cf Bitcoin nodes: how many is enough?], Jameson Lopp, 7 June 2015</ref><br />
<br />
Full nodes need to download and verify every block, and most nodes also store blocks plus relay transactions, full blocks, and filtered blocks to other users on the network. The bigger blocks become, the more difficult it becomes to do all this, so it is expected that bigger blocks will both reduce the number of users who currently run full nodes and suppress the number of users who decide to start running a full node later.<ref>[https://www.reddit.com/r/Bitcoin/comments/3bae2d/amir_taaki_on_raising_the_block_size_a_lot_of/cslcgmw Block size increases-only will create problems], Dr. Adam Back, 28 June 2015</ref><br />
<br />
In addition, full blocks may increase mining centralization<ref name="wuille_centralization" /> at a time when mining is already so centralized that it makes it easy to reverse transactions which have been confirmed multiple times.<ref>[http://bitcoin.stackexchange.com/questions/32562/when-to-worry-about-1-confirmation-payments/32564#32564 When to worry about one-confirmation payments], David A. Harding, 17 November 2014</ref><br />
<br />
==== How could larger blocks affect proof-of-work (POW) security? ====<br />
<br />
Proof of work security is dependent on how much money miners spend on mining equipment. However, to effectively mine blocks, miners also need to spend money on bandwidth to receive new transactions and blocks created by other miners; CPUs to validate received transactions and blocks; and bandwidth to upload new blocks. These additional costs don’t directly contribute to POW security.<ref name="maxwell_correcting_assumptions">[https://www.reddit.com/r/Bitcoin/comments/39tgno/letting_miners_vote_on_the_maximum_block_size_is/cs6rek5 Correcting wrong assumptions about mining], Gregory Maxwell, 15 June 2015</ref><br />
<br />
As block sizes increase, the amount of bandwidth and CPU required also increases. If block sizes increase faster than the costs of bandwidth and CPU decrease, miners will have less money for POW security relative to the gross income they earn.<br />
<br />
In addition, larger blocks have a higher risk of becoming stale (orphaned)<ref name="rusty_dsl" />, which directly correlates to lost POW security. For example, if the network average stale rate is 10%, then 10% of POW performed isn't protecting transactions on the block chain.<br />
<br />
=== What happens if blocks aren't big enough to include all pending transactions? ===<br />
<br />
This is already the case more often than not<ref>[http://statoshi.info/dashboard/db/transactions?from=1433297061121&to=1435889061123 Statoshi.info mempool queue June to July 2015]</ref>, so we know that miners will simply queue transactions. The transactions eligible for block inclusion that pay the highest fee per kilobyte will be confirmed earlier than transactions that pay comparatively lower fees.<ref name="fee_pri" /><br />
<br />
What happens from there is debated:<br />
<br />
* BitcoinJ lead developer Mike Hearn believes there would be “crashing nodes, a swelling transaction backlog, a sudden spike in double spending, [and] skyrocketing fees.”<ref>[https://medium.com/@octskyward/crash-landing-f5cc19908e32 Crash Landing], Mike Hearn, 7 May 2015</ref><br />
* Bitcoin Foundation chief scientist Gavin Andresen believes that the “average transaction fee paid will rise, people or applications unwilling or unable to pay the rising fees will stop submitting transactions, [and] people and businesses will shelve plans to use Bitcoin, stunting growth and adoption.” <ref>[https://github.com/bitcoin/bitcoin/pull/6341 Bitcoin Core pull #6341], Gavin Andresen, 26 June 2015</ref><br />
* Bitcoin Core developer Pieter Wuille replies to Andresen’s comment above: “Is it fair to summarize this as ‘Some use cases won’t fit any more, people will decide to no longer use the blockchain for these purposes, and the fees will adapt.’? I think that is already happening […] I don’t think we should be afraid of this change or try to stop it.” <ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009098.html The need for larger blocks], Pieter Wuille, 26 June 2015</ref><br />
* Bitcoin Core developer Jeff Garzik writes, "as blocks get full and the bidding war ensues, the bitcoin user experience rapidly degrades to poor. In part due to bitcoin wallet software’s relative immaturity, and in part due to bitcoin’s settlement based design, the end user experience of their transaction competing for block size results in erratic, and unpredictably extended validation times."<ref name="garzik_bip" /><br />
<br />
== Specific Scaling Proposals ==<br />
<br />
=== Andresen-Hearn Block Size Increase Proposals ===<br />
<br />
Questions about the series of related proposals by Gavin Andresen and Mike Hearn to use a hard fork to raise the maximum block size, thereby allowing miners to include more on-chain transactions. As of July 2015, the current focus is [https://github.com/bitcoin/bips/pull/163 BIP101].<br />
<br />
==== What is the major advantage of this proposal? ====<br />
<br />
''Bitcoin can support many more users.'' Assuming earliest possible adoption, 250 bytes per on-chain transaction, 144 blocks per day, and 2 transaction a day per user, Bitcoin can support about,<br />
<br />
* 288,000 users in 2015<br />
* 2,304,000 users in 2016 (800% increase)<br />
* 4,608,000 in 2018 (1,600%)<br />
* 9,216,000 in 2020 (3,200%)<br />
* 18,432,000 in 2022 (6,400%)<br />
* 36,864,000 in 2024 (12,800%)<br />
* 73,728,000 in 2026 (25,600%)<br />
* 147,456,000 in 2028 (51,200%)<br />
* 294,912,000 in 2030 (102,400%)<br />
* 589,824,000 in 2032 (204,800%)<br />
* 1,179,648,000 in 2034 (409,600%<br />
* 2,359,296,000 in 2036 (819,200%)<br />
<br />
==== What is the major disadvantage of this proposal? ====<br />
<br />
''The total cost of remaining decentralized will be high.'' Assuming earliest possible adoption and that the ratio of total users to full node operators remains the same as today, the total estimated amount of work necessary to maintain the decentralized system under the [[#O.28n2.29_network_total_validation_resource_requirements|O(<sup>2</sup>) scaling model]] will be,<br />
<br />
* 100% of today’s work in 2015<br />
* 6,400% in 2016<br />
* 25,600% in 2018<br />
* 102,400% in 2020<br />
* 409,600% in 2022<br />
* 1,638,400% in 2024<br />
* 6,553,600% in 2026<br />
* 26,214,400% in 2028<br />
* 104,857,600% in 2030<br />
* 419,430,400% in 2032<br />
* 1,677,721,600% in 2034<br />
* 6,710,886,400% in 2036<br />
<br />
For example, if the total amount spent on running full nodes today (not counting mining) is $100 thousand per year, the estimated cost for the same level of decentralization in 2036 will be $6.7 trillion per year if validation costs stay the same. (They'll certainly go down, but algorithmic and hardware improvements probably won't eliminate an approximate 6,710,886,400% cost increase.)<br />
<br />
==== What are the dangers of the proposed hard fork? ====<br />
<br />
Under the current proposal, 75% of miners must indicate that they agree to accept blocks up to 8 MB in size.<ref name="bip101">[https://github.com/bitcoin/bips/pull/163 BIP101], Gavin Andresen, 24 June 2016</ref> After the change goes into effect, if any miner creates a block larger than 1 MB, all nodes which have not upgraded yet will reject the block.<ref>[https://bitcoin.org/en/developer-guide#consensus-rule-changes Consensus rule changes], Bitcoin.org Developer Guide</ref><br />
<br />
If all full nodes have upgraded, or very close to all nodes, there should be no practical effect. If a significant number of full nodes have not upgraded, they will continue using a different block chain than the upgraded users, with the following consequences:<br />
<br />
* Bitcoins received from before the fork can be spent twice, once on both sides of the fork. This creates a high double spend risk.<br />
* Bitcoins received after the fork are only guaranteed to be spendable on the side of the fork they were received on. This means some users will have to lose money to restore Bitcoin to a single chain.<br />
<br />
Users of hosted wallets (Coinbase, BlockChain.info, etc.) will use whatever block chain their host chooses. Users of lightweight P2P SPV wallets will use the [[Thin Client Security|longest chain they know of]], which may not be the actual longest chain if they only connect to nodes on the shorter chain. Users of non-P2P SPV wallets, like Electrum, will use whatever chain is used by the server they connect to.<br />
<br />
If a bad hard fork like this happens, it will likely cause large-scale confusion and make Bitcoin very hard to use until the situation is resolved.<br />
<br />
==== What is the deployment schedule for BIP 101? ====<br />
<br />
* The patch needs to be accepted into Bitcoin Core, Bitcoin XT, or both.<br />
* If accepted into Bitcoin Core, miners using that software will need to upgrade (this probably requires a new released version of Bitcoin Core). If accepted only into Bitcoin XT, miners will need to switch to using XT.<br />
* After 75% of miners have upgraded, 8MB blocks will become allowed at the the latest of (1) 11 January 2016 or (2) two weeks after the 75% upgrade threshold.<ref name="bip101" /><br />
* After the effective date has passed, any miner may create a block larger than 8MB. When a miner does this, upgraded full nodes will accept that block and non-upgraded full nodes will reject it, forking the network.<ref name="bip101" /> See [[#What_are_the_dangers_of_the_proposed_hard_fork.3F|hard fork dangers]] for what his might mean.<br />
<br />
==== Will miners go straight from 1 MB blocks to 8 MB blocks? ====<br />
<br />
That would be highly unlikely. Uploading an 8 MB block currently takes significantly more time than uploading a 1 MB block<ref name="rusty_dsl">[http://rusty.ozlabs.org/?p=509 Mining on a home DSL connection test results], Rusty Russell, 19 June 2015</ref>, even with the roughly 25x reduction in size available from use of Matt Corallo’s block relay network.<ref name="block_relay_net" /><br />
<br />
The longer it takes to upload a block, the higher the risk it will become a stale block—meaning the miner who created it will not receive the block subsidy or transaction fees (currently about 25 BTC per block).<br />
<br />
However, if technology like Invertible Bloom Lookup Tables (IBLTs) is deployed and found to work as expected<ref name="iblt">[https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2 O(1) block propagation], Gavin Andresen, 8 August 2014</ref>, or if mining [[#What_is_the_most_efficient_way_to_scale_Bitcoin.3F|centralizes further]], adding additional transactions may not have a significant enough cost to discourage miners from creating full blocks. In that case, blocks will be filled as soon as there are enough people wanting to make transactions paying the default relay fee<ref>[https://github.com/bitcoin/bitcoin/pull/3305 Bitcoin Core pull #3305 dropping default fees], Mike Hearn, 22 November 2013</ref> of 0.00001000 BTC/kilobyte.<br />
<br />
==== What tests have been performed related to this proposal? ====<br />
<br />
* '''20MB block processing''' (Gavin Andresen) “if we increased the maximum block size to 20 megabytes tomorrow, and every single miner decided to start creating 20MB blocks and there was a sudden increase in the number of transactions on the network to fill up those blocks… the 0.10.0 version of [Bitcoin Core] would run just fine.”<ref>[http://gavintech.blogspot.com/2015/01/twenty-megabytes-testing-results.html Twenty megabyte block testing], Gavin Andresen, 20 January 2015</ref> (ellipses in original)<br />
* '''Mining &amp; relay simulation''' (Gavin Andresen) “if blocks take 20 seconds to propagate, a network with a miner that has 30% of the hashing power will get 30.3% of the blocks.”<ref>[http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners Are bigger blocks better for bigger miners?], Gavin Andresen, 22 May 2015</ref><br />
* '''Mining on a home DSL connection''' (Rusty Russell) “Using the rough formula of 1-exp(-t/600), I would expect orphan rates of 10.5% generating 1MB blocks, and 56.6% with 8MB blocks; that’s a huge cut in expected profits.”<ref name="rusty_dsl" /><br />
* '''Mining centralization pressure''' (Pieter Wuille) “[This] does very clearly show the effects of larger blocks on centralization pressure of the system.”<ref name="wuille_centralization">[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008581.html Mining centralization pressure from non-uniform propagation speed], Pieter Wuille, 12 June 2015</ref><br />
<br />
<br />
=== Garzik Miner Block Size Voting Proposal (AKA BIP100) ===<br />
<br />
''Note, BIP 100 is the marketing name for this proposal. No BIP number<br />
has yet been publicly requested, and the number assigned is unlikely to<br />
be 100.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-May/005756.html<br />
Prenumbered BIP naming], Gregory Maxwell, 12 May 2014</ref>''<br />
<br />
Questions related to Jeff Garzik's proposal<ref name="garzik_bip">[http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf Draft BIP: decentralized economic policy], Jeff Garzik, 12 June 2015 (revised 15 June 2015)</ref> to allow miners to vote on raising and lowering the maximum block size.<br />
<br />
==== What does this proposal do? ====<br />
<br />
# It creates a one-time hard fork that does not automatically change the maximum block size.<br />
<br />
# It allows miners to vote to increase or decrease the maximum block size within the range of 1MB to 32MB. These changes are neither hard forks nor soft forks, but simply rules that all nodes should know about after the initial hard fork.<br />
<br />
==== Does it reduce the risk of a hard fork? ====<br />
<br />
Hard forks are most dangerous when they're done without strong<br />
consensus.<ref name="garzik_bip" /><ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008779.html Consensus changes are not about making a change to the software],<br />
Pieter Wuille, 18 June 2015</ref><br />
<br />
If Garzik's proposal gains strong consensus, it will be as safe as possible<br />
for a hard fork and it will allow increasing the block size up to 32 MB<br />
without any additional risk of a fork.<br />
<br />
==== Why is it limited to 32 megabytes? ====<br />
<br />
According to the draft BIP, "the 32 MB hard fork is largely coincidental -- a whole network upgrade at 32 MB was likely needed anyway."<br />
<br />
=== Lightning Network ===<br />
<br />
Questions related to using the proposed [http://lightning.network/ Lightning network] as a way to scale the number of users Bitcoin can support.<br />
<br />
==== How does transaction security differ from that of Bitcoin? ====<br />
<br />
Transactions on the proposed Lightning network use Bitcoin transactions exclusively to transfer bitcoins<ref name="russell_lightning1">[http://rusty.ozlabs.org/?p=450 Lightning Networks: Part I], Rusty Russell, 30 March 2015</ref>, and so the same security as regular Bitcoin transactions is provided when both a Lightning hub and client are cooperating.<br />
<br />
When a Lightning hub or client refuses to cooperate with the other (maybe because they accidentally went offline), the other party can still receive their full 100% bitcoin balance by closing the payment channel—but they must first wait for a defined amount of time mutually chosen by both the hub and client.<ref>[http://rusty.ozlabs.org/?p=462 Lightning Networks: Part II], Rusty Russell, 1 April 2015</ref><br />
<br />
If one party waits too long to close the payment channel, the other party may be able to steal bitcoins. However, it is possible to delegate the task of closing the channel in an emergency to an unlimited number of hubs around the Internet, so closing the channel on time should be easy.<ref name="russell_lightning4">[http://rusty.ozlabs.org/?p=477 Lightning Networks: Part IV], Rusty Russell, 8 April 2015</ref><br />
<br />
In summary, provided that payment channels are closed on time, the worst that can happen to users is that they may have to wait a few weeks for a channel to fully close before spending the bitcoins they received from it. Their security is otherwise the same as with regular Bitcoin.<br />
<br />
For Lightning hubs, security is slightly worse in the sense that they need to keep a potentially-large amount of funds in a hot wallet<ref name="lightning_paper">[http://lightning.network/lightning-network-paper-DRAFT-0.5.pdf Lightning Network (Draft 0.5)], Section 6.3: Coin Theft via Hacking, Joseph Poon and Thaddeus Dryja</ref>, so they can’t take advantage of the anti-hacking protection offered by cold wallets. Otherwise, Lightning hubs have the same security as clients.<br />
<br />
==== When will Lightning be ready for use? ====<br />
<br />
Lightning requires a basic test implementation (work underway<ref>[https://lists.blockstream.com/pipermail/lightning-dev/2015-June/000018.html Lightning first steps], Rusty Russell, 13 June 2015</ref>), several soft-fork changes to the Bitcoin protocol (work underway<ref>[https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65: CheckLockTimeVerify], Peter Todd, 1 October 2014</ref><ref>[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68: Consensus-enforced transaction replacement], Mark Friedenbach, 28 May 2015</ref>, and wallets need to be updated to support the Lightning network protocol.<ref name="russell_lightning4" /><br />
<br />
Dr. Adam Back has said, "I expect we can get something running inside a year."<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009242.html Reply to Andresen regarding Lightning], Dr. Adam Back, 28 June 2015</ref><br />
<br />
==== Doesn’t Lightning require bigger blocks anyway? ====<br />
<br />
Lightning is block-size neutral. It requires one on-chain transaction to open a channel between a hub and a client, and one on-chain transaction to close a channel.<ref name="russell_lightning1" /> In between it can support an unlimited number of transactions between anyone on the Lightning network.<ref name="lightning_paper" /><br />
<br />
Using the numbers from the Lightning presentation<ref name="lightning_slides">[http://lightning.network/lightning-network.pdf Lightning presentation], Joseph Poon, 23 February 2015</ref>, if people open and close a plausible two channels a year, Lightning can support about 52 million users with the current one-megabyte limit—and each user can make an unlimited number of transactions. Currently, assuming people make an average of only two Bitcoin transactions a day, basic Bitcoin can support only 288,000 users.<br />
<br />
Under these assumptions, Lightning is 180 times (17,900%) more efficient than basic Bitcoin.<br />
<br />
Presumably, if around 30 million people are using Bitcoin via Lightning so that capacity is called into question, it will not be difficult to find consensus to double the block size to two megabytes and bring user capacity up to 105 million. The same goes for later increases to 200 million (4MB), 400 million (8MB), 800 million (16MB), 1.6 billion (32 MB), 3.2 billion (64MB), and all 7 billion living humans (133MB). In each case, all Lightning network participants get unlimited transactions to the other participants.<br />
<br />
For basic Bitcoin to scale to just 2 transactions a day for 7 billion people would require 24-gigabyte blocks.<ref name="lightning_slides" /><br />
<br />
=== Sidechains ===<br />
<br />
==== Real quick, what are sidechains? ====<br />
<br />
Block chains that are separate from Bitcoin’s block chain, but which allow you to receive and spend bitcoins using a two-way peg (2WP).<ref name="sidechains_paper">[https://www.blockstream.com/sidechains.pdf Sidechains paper], Adam Back et al., 22 October 2014</ref> (Although a sidechain can never be more secure than the Bitcoin block chain.<ref>[https://www.reddit.com/r/Bitcoin/comments/39r85g/sidechain_hate/cs5spbg Security limitations of pegged chains], Gregory Maxwell, 14 June 2015</ref>)<br />
<br />
==== Are sidechains a scaling option? ====<br />
<br />
No. Sidechains have the same fundamental scaling problems as Bitcoin does. Moving some transactions to sidechains simply moves some problems elsewhere on the network—the total difficulty of the problem remains the same.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008617.html Sidechains not a direct means for solving any of the scaling problems Bitcoin has], Pieter Wuille, 13 June 2015</ref><br />
<br />
==== But couldn’t I create a sidechain that had 100 GB blocks? ====<br />
<br />
Certainly, sidechain code is open source<ref>[https://github.com/ElementsProject/elements Elements Project]</ref>—so you can create your own sidechain. But you’d still have the difficulty of finding people who are willing to validate 100 GB blocks with their own full nodes.<br />
<br />
==== Do sidechains require a hard fork? ====<br />
<br />
No. Federated sidechains, such as have already been implemented<ref>[https://github.com/ElementsProject/elements/tree/alpha Elements Alpha]</ref>, don’t require any changes to the Bitcoin consensus rules. Merged-mined sidechains, which have not been implemented yet, do require a backwards-compatible soft fork in order to transfer funds between Bitcoin and the sidechain.<ref name="sidechains_paper" /><br />
<br />
== References ==<br />
<references /></div>Amincdhttps://en.bitcoin.it/w/index.php?title=Scalability&diff=57431Scalability2015-07-10T04:16:36Z<p>Amincd: corrected incorrect processor requirement claim</p>
<hr />
<div>The core Bitcoin network can scale to much higher transaction rates than are seen today, assuming that nodes in the network are primarily running on high end servers rather than desktops. Bitcoin was designed to support lightweight clients that only process small parts of the block chain (see ''simplified payment verification'' below for more details on this). A configuration in which the vast majority of users sync lightweight clients to full nodes.<br />
<br />
The requirement of expensive full nodes is controversial. While having a high-capacity set of full nodes increases the on-blockchain transaction rate, the requirement of full nodes to be high capacity has a centralizing effect. Scalability solutions that don't require high capacity full nodes include sidechains and the Lightning Network.<br />
<br />
==Scalability targets==<br />
<br />
VISA handles on average around 2,000 transactions per second (tps), so call it a daily peak rate of 4,000 tps. It has a peak capacity of around 56,000 transactions per second, [http://usa.visa.com/about-visa/our-business/visa-transaction.js] however they never actually use more than about a third of this even during peak shopping periods. [http://www.visa.com/blogarchives/us/2013/10/10/stress-test-prepares-visanet-for-the-most-wonderful-time-of-the-year/index.html]<br />
<br />
PayPal, in contrast, handles around 10 million transactions per day for an average of 115 tps. [https://www.paypal-media.com/about]<br />
<br />
Let's take 4,000 tps as starting goal. Obviously if we want Bitcoin to scale to all economic transactions worldwide, including cash, it'd be a lot higher than that, perhaps more in the region of a few hundred thousand tps. And the need to be able to withstand DoS attacks (which VISA does not have to deal with) implies we would want to scale far beyond the standard peak rates. Still, picking a target let us do some basic calculations even if it's a little arbitrary.<br />
<br />
Today the Bitcoin network is restricted to a sustained rate of 7 tps due to the bitcoin protocol restricting block sizes to 1MB.<br />
<br />
==Increasing Block Size==<br />
<br />
Increasing the blocksize is the easiest solution to implement, as it only requires changing one line of code, and is possible today. However, increasing the power of full nodes increases the cost and increasing the cost of full nodes has a centralizing effect. While a miner can run a full node, they have less and less reason to as blocks become more and more expensive to process. As less miners run full nodes, power over the mining network and ability to reverse transactions increases.<ref>[https://people.xiph.org/~greg/attack_success.html Miner Attack Success Probability Calculator]</ref><ref>[https://bitcoin.org/bitcoin.pdf Bitcoin Whitepaper]</ref> <br />
<br />
===CPU===<br />
<br />
The protocol has two parts. Nodes send "inv" messages to other nodes telling them they have a new transaction. If the receiving node doesn't have that transaction it requests it with a getdata.<br />
<br />
The big cost is the crypto and block chain lookups involved with verifying the transaction. Verifying a transaction means some hashing and some [[ECDSA]] signature verifications. RIPEMD-160 runs at 106 megabytes/sec (call it 100 for simplicity) and SHA256 is about the same. So hashing 1 megabyte should take around 10 milliseconds and hashing 1 kilobyte would take 0.01 milliseconds - fast enough that we can ignore it.<br />
<br />
Bitcoin is currently able (with a couple of simple optimizations that are prototyped but not merged yet) to perform around 8000 signature verifications per second on an quad core [http://ark.intel.com/products/53469 Intel Core i7-2670QM 2.2Ghz processor]. The average number of inputs per transaction is around 2, so we must halve the rate. This means 4000 tps is easily achievable CPU-wise with a single fairly mainstream CPU.<br />
<br />
As we can see, this means as long as Bitcoin nodes are allowed to max out at least 4 cores of the machines they run on, we will not run out of CPU capacity for signature checking unless Bitcoin is handling 100 times as much traffic as PayPal. As of late 2012 the network is handling 0.5 transactions/second, so even assuming enormous growth in popularity we will not reach this level for a long time.<br />
<br />
Of course Bitcoin does other things beyond signature checking, most obviously, managing the database. We use LevelDB which does the bulk of the heavy lifting on a separate thread, and is capable of very high read/write loads. Overall Bitcoin's CPU usage is dominated by ECDSA.<br />
<br />
===Network===<br />
<br />
Let's assume an average rate of 2000tps, so just VISA. Transactions vary in size from about 0.2 kilobytes to over 1 kilobyte, but it's averaging half a kilobyte today.<br />
<br />
That means that you need to keep up with around 8 megabits/second of transaction data (2000tps * 512 bytes) / 1024 bytes in a kilobyte / 1024 kilobytes in a megabyte = 0.97 megabytes per second * 8 = 7.8 megabits/second.<br />
<br />
This sort of bandwidth is already common for even residential connections today, and is certainly at the low end of what colocation providers would expect to provide you with.<br />
<br />
When blocks are solved, the current protocol will send the transactions again, even if a peer has already seen it at broadcast time. Fixing this to make blocks just list of hashes would resolve the issue and make the bandwidth needed for block broadcast negligable. So whilst this optimization isn't fully implemented today, we do not consider block transmission bandwidth here.<br />
<br />
===Storage===<br />
<br />
At very high transaction rates each block can be over half a gigabyte in size.<br />
<br />
It is not required for most fully validating nodes to store the entire chain. In Satoshi's paper he describes "pruning", a way to delete unnecessary data about transactions that are fully spent. This reduces the amount of data that is needed for a fully validating node to be only the size of the current unspent output size, plus some additional data that is needed to handle re-orgs. As of October 2012 (block 203258) there have been 7,979,231 transactions, however the size of the unspent output set is less than 100MiB, which is small enough to easily fit in RAM for even quite old computers.<br />
<br />
Only a small number of archival nodes need to store the full chain going back to the genesis block. These nodes can be used to bootstrap new fully validating nodes from scratch but are otherwise unnecessary.<br />
<br />
The primary limiting factor in Bitcoin's performance is disk seeks once the unspent transaction output set stops fitting in memory. It is quite possible that the set will always fit in memory on dedicated server class machines, if hardware advances faster than Bitcoin usage does.<br />
<br />
==Lightning Network==<br />
<br />
To account for 2 transactions per day for every human on earth, blocks would need to be 24GB, and would require the processing power of approximately 40 Intel Core i7-2670QM 2.2Ghz processors. Some argue that as block sizes increase, we cannot simply throw more resources at processing blocks unless said resources become cheaper at a rate faster than the need for these resources increases, claiming it will result in a few centralized parties that control the blockchain and are able to reverse or censor transactions. Others argue that under any realistic maximum usage scenario, like in the case of 24 GB blocks, full node requirements will not be so great that they lead to a dangerous level of centralization, and that the situation will only get better with time as processor cost performance improves.<br />
<br />
The Lightning Network can provide trustless off-chain transactions and scales better than O(N*M) (requiring every full node to have every unspent output). Other advantages include not having a counterparty risk, no one can steal your bitcoin. Despite Lightning transactions being trustless, the system doesn't require everyone to process a copy of transactions from everyone else in order to be secure. In addition, Lightning has instant confirmations and doesn't require a hardfork.<ref>[http://lightning.network/lightning-network.pdf Lighting Network]</ref> Due to these assumed qualities of the Lightning Network, those wary of the potential centralizing effects of large blocks believe this technology can almost totally replace increases in block size as the means to scale Bitcoin usage.<br />
<br />
==Optimizations==<br />
<br />
The description above applies to the current software with only minor optimizations assumed (the type that can and have been done by one man in a few weeks). <br />
<br />
However there is potential for even greater optimizations to be made in future, at the cost of some additional complexity.<br />
<br />
===CPU===<br />
<br />
Pieter Wuille has implemented a custom verifier tuned for secp256k1 that can go beyond 20,000 signature verifications per second. It would require careful review by professional cryptographers to gain as much confidence as OpenSSL, but this can easily halve CPU load.<br />
<br />
Algorithms exist to accelerate batch verification over elliptic curve signatures. This means if there are several inputs that are signing with the same key, it's possible to check their signatures simultaneously for another 9x speedup. This is a somewhat more complex implementation, however, it can work with existing signatures (clients don't need upgrading).<br />
<br />
Newly developed digital signature algorithms, like [http://ed25519.cr.yp.to/ed25519-20110705.pdf ed25519] have extremely efficient software implementations that can reach speeds of nearly 80,000 verifications per second, even on an old Westmere CPU. That is a 10x improvement over secp256k1, and most likely is even higher on more modern CPUs. Supporting this in Bitcoin would mean a chain fork. This ECC algorithm has also been shown to be [http://eprint.iacr.org/2014/198 easily accelerated using GPUs], yielding scalar point multiplication times of less than a microsecond (i.e. a million point multiplications per second).<br />
<br />
At these speeds it is likely that disk and memory bandwidth would become the primary limiting factor, rather than signature checking.<br />
<br />
===Simplified payment verification===<br />
<!-- "Simplified payment verification" redirects here. Update the redirect if you change the section title --><br />
<br />
It's possible to build a Bitcoin implementation that does not verify everything, but instead relies on either connecting to a trusted node, or puts its faith in high difficulty as a proxy for proof of validity. [[bitcoinj]] is an implementation of this mode.<br />
<br />
In Simplified Payment Verification (SPV) mode, named after the section of Satoshi's paper that describes it, clients connect to an arbitrary full node and download only the block headers. They verify the chain headers connect together correctly and that the difficulty is high enough. They then request transactions matching particular patterns from the remote node (ie, payments to your addresses), which provides copies of those transactions along with a Merkle branch linking them to the block in which they appeared. This exploits the Merkle tree structure to allow proof of inclusion without needing the full contents of the block. <br />
<br />
As a further optimization, block headers that are buried sufficiently deep can be thrown away after some time (eg. you only really need to store as low as 2016 headers).<br />
<br />
The level of difficulty required to obtain confidence the remote node is not feeding you fictional transactions depends on your threat model. If you are connecting to a node that is known to be reliable, the difficulty doesn't matter. If you want to pick a random node, the cost for an attacker to mine a block sequence containing a bogus transaction should be higher than the value to be obtained by defrauding you. By changing how deeply buried the block must be, you can trade off confirmation time vs cost of an attack.<br />
<br />
Programs implementing this approach can have fixed storage/network overhead in the null case of no usage, and resource usage proportional to received/sent transactions.<br />
<br />
See also: [[Thin Client Security]].<br />
<br />
== Related work ==<br />
There are a few proposals for optimizing Bitcoin's scalability. Some of these require an alt-chain / hard fork.<br />
<br />
* [https://bitcointalk.org/index.php?topic=88208.0 Ultimate blockchain compression] - the idea that the blockchain can be compressed to achieve "trust-free lite nodes"<br />
* [http://www.bitfreak.info/files/pp2p-ccmbc-rev1.pdf The Finite Blockchain] paper that describes splitting the blockchain into three data structures, each better suited for its purpose. The three data structures are a finite blockchain (keep N blocks into the past), an "account tree" which keeps account balance for every address with a non-zero balance, and a "proof chain" which is an (ever growing) slimmed down version of the blockchain.<br />
<br />
[[Category:Technical]]</div>Amincdhttps://en.bitcoin.it/w/index.php?title=Merchant_Howto&diff=48656Merchant Howto2014-07-06T08:27:33Z<p>Amincd: /* Services */ removed discontinued services</p>
<hr />
<div>{{merge|How to accept Bitcoin, for small businesses}}<br />
<br />
Accepting Bitcoins is easy, and there are several ways to do it.<br />
<br />
==Manually==<br />
# Download a bitcoin client<br />
# When a customer wants to buy something, send them a Bitcoin address where their payment should be sent.<br />
#* You can do this by clicking "New.." next to your address in the Bitcoin client and sending that address to the customer.<br />
# When payment comes in to that address, send the goods to your customer. Depending on the value of what you're selling, you may wish to wait until the payment shows Confirmed.<br />
# To issue a refund, obtain from the customer the [[Address|bitcoin address]] where the refund payment should be sent. The refund address will likely be different from the address used when the customer sent payment, especially if an [[EWallet]] was used by the customer.<br />
<br />
==Automated==<br />
===Pre-generating Bitcoin addresses===<br />
You can accept Bitcoins on your website without needing to use Bitcoin APIs or third party services if you pre-generate a large number of receiving Bitcoin addresses and store them in a database on your web server, and dispense them one-by-one to customers when they are ready to pay. This way, your web server never actually handles the bitcoins - it simply gives out addresses belonging to a wallet you maintain elsewhere. By using a unique address per order, you will always know which payment belongs to which order. [https://www.casascius.com Example of website using this method]<br />
<br />
To pre-generate addresses, use a tool such as [[Pywallet]] (which can generate a wallet.dat file) or [[Bitcoin Address Utility]] (which can generate a CSV file). In both cases, you will be generating a list of [[Address|Bitcoin address]]es along with their corresponding [[private key]]s. Only the Bitcoin addresses (not the private keys) should be loaded on the web server.<br />
<br />
If you are shipping goods manually, you can use the Bitcoin software to check for incoming payments, or alternately consider using [[Block Explorer]] or [[Abe]] to verify payment when you're about to ship. To make this easy, make your website provide you a full hyperlink that includes the proper receiving address: ht<nowiki>tp://www</nowiki>.blockexplorer.com/address/ADDRESSGOESHERE.<br />
<br />
If you are delivering digital goods or services and want to be able to deliver instantly upon payment and/or confirmation, you can use a third-party service such as [[Bitcoin Notify]] to tell your website when a payment has been received. This sort of service requires no significant API implementation - they will simply make a POST to your website or send you an e-mail when a payment has been received on one of your addresses.<br />
<br />
If you keep Bitcoins off your web server, this ensures your wallet cannot be stolen if your web server experiences a security intrusion. Your risk becomes limited to the possibility that a successful intruder could add his own addresses to your address pool and steal funds from a few incoming orders until you detect the problem, however, this is a relatively controllable risk.<br />
<br />
===Using offchain payment networks===<br />
<br />
[[Off-Chain_Transactions|Off chain]] networks provides various benefits to Bitcoin, such as instant confirmations and protection against double spending.<br />
<br />
===Using a third-party plugin===<br />
You can use an existing [[:Category:Shopping Cart Interfaces|shopping cart interface]] from a 3rd party to automatically handle all Bitcoin payments on your website. If you want to develop the system yourself, you can utilize the Bitcoin client's [[API tutorial (JSON-RPC)|JSON-RPC API]] to automatically accept payments.<br />
<br />
Things to note if you build it yourself:<br />
# When a customer orders something on your website it records:<br />
#* Bitcoin address that payment should be sent to<br />
#* Order details (delivery address etc.)<br />
#* Customer's refund address (optional - if you wish you can ask for this later, only in cases a refund is required)<br />
#* Payment amount<br />
# When payment arrives, checks that they have paid the correct amount or not, and informs you<br />
#* You dispatch the goods to the customer and mark the order as fulfilled<br />
#* If you cannot dispatch the goods you mark the order as denied and ask the customer for a refund address (unless you already have it from earlier) to send a refund.<br />
# Forwards the funds to bitcoin address of your choice<br />
<br />
===Businesses that mail invoices===<br />
Does your business send out invoices to customers? Adding one line may make a huge impact for the Bitcoin economy. Perhaps you list it as a payment option just after Visa, MasterCard, and American Express, even if that means your customer must call or e-mail to make a payment. However it is possible to create automated invoices by using known payment systems supporting invoicing, and recurring invoice setup.<br />
<br />
==Common Errors==<br />
It has been observed on occasion that a business funnels all its orders through the same Bitcoin address, and asks people to send some BTC, then send email describing the timing and the amount of the transaction to 'claim' it. This is '''not''' secure, since anyone can see the transaction details using a tool such as [[Block Explorer]], and then try to claim someone else's transaction as theirs.<br />
<br />
Do not do this. Give each customer a unique Bitcoin address.<br />
<br />
==Listing your business on the Bitcoin Trade page==<br />
<br />
Anyone can add and update a listing on the [[Trade|trade]] page. Just register if you haven't and add to the appropriate category. If you'ld like assistance, perhaps someone in the [http://webchat.freenode.net/?channels=#bitcoin-marketing #bitcoin-marketing] IRC channel would be willing to assist.<br />
<br />
==Services==<br />
* [http://www.dcpos.com DC POS] A Bitcoin browser-based Point-of-Sale app. It is hardware, OS, wallet, and browser agnostic. 0.5% transaction fee.<br />
* [[File:BIPS.gif|20px|link=https://bips.me]] [[BIPS]] Merchant solutions for Bitcoin<br />
* [https://bitcoinpay.com BitcoinPay] Merchant solution for Bitcoin specialized in Middle Europe (Germany, Poland, Slovakia, Czech republic)<br />
* [https://www.BitKassa.nl BitKassa] Merchant solution for accepting bitcoins, getting euro's. No fee. The Netherlands.<br />
* [[BitPay]] Merchant solutions for Bitcoin<br />
*[[BTCMerch]] - Payment processor for bitcoins and other cryptocurrencies. 0.5% transaction fee. Sandbox is available.<br />
* [[BitMerch]] Bitcoin payment processor with 0.5% transaction fee.<br />
* [http://www.bitpagos.net BitPagos] Payments Gateway for Latin America<br />
* [https://coinbase.com/merchants Coinbase] Offers payment buttons, pages, iframes, shopping cart integration, subscription/recurring billing, micro-transactions, and cash out to your local currency for 1%.<br />
* [[File:MCS_200by200_logo-01.png|20px|link=http://www.mycoinsolution.com]][http://www.mycoinsolution.com My Coin Solution] - Bitcoin consulting services and solutions<br />
* [[File:Coinkite.gif|20px|link=https://coinkite.com]] [https://coinkite.com/faq Coinkite] Full-reserve banking, payment buttons, invoice pages, hardware POS terminals, and Debit-Cards.<br />
* [https://xbterminal.com/ XBTerminal] Brick-and-mortar hardware POS terminals with payment processing integrations.<br />
* [http://paysius.com Paysius] Allows merchants to easily and securely accept Bitcoin payments on their website<br />
* [[File:gocoin-logo.png|20px|link=https://www.gocoin.com]] [[GoCoin]] International Payment Processing for Bitcoin<br />
<br />
==See Also==<br />
* [[In-store Transactions]]<br />
* [[:Category:Shopping Cart Interfaces|Shopping Cart Interfaces]]<br />
* [[Securing online services]]<br />
* [[Bitcoin Evolution]] handles sales tracking and order forms; requires Bitcoin client for actual payment<br />
* [[Bitcoin API Services]] an easy solution for securely accepting Bitcoins and updating BTC prices<br />
* [[Converter|Bitcoin Javascript Converter]] displays a price in BTCs after converting from USDs.<br />
* [[How to accept Bitcoin, for small businesses]]<br />
* [[:Category:Marketing|Marketing]]<br />
* [[URI Scheme]]<br />
* [[Promotional graphics]], buttons and logos<br />
* [[Lazy API]] The lazy (and possibly easiest?) way to accept bitcoin payments on your website<br />
* [http://snowcron.com Snowcron] Bitcoin Store Engine: Handles payments, sends your customers information they ordered (reg. codes, passwords...) No web programming required.<br />
[[Category:ECommerce]]</div>Amincdhttps://en.bitcoin.it/w/index.php?title=Help:Getting_started&diff=45962Help:Getting started2014-04-05T22:31:34Z<p>Amincd: </p>
<hr />
<div>Here is a generic [[Bitcoin_Newbie_Guide|Getting Started guide]].<br />
* Get started buying bitcoins at [http://coinbase.com/ Coinbase]<br />
* Get free bitcoins and learn to use them in 5 minutes: [https://trybtc.com TryBTC]<br />
* If you have old electronics (iPhones, iPads, Androids, etc), you can trade them in for bitcoin at [http://glyde.com/ Glyde] or [https://www.mintspare.com/ Mintspare].<br />
* Start by watching [http://weusecoins.com/ this 2 minute vid].<br />
* Learn why it [http://bitcoin.stackexchange.com/questions/2834/what-are-the-perceived-advantages-of-bitcoin-as-a-store-of-value could be a good investment]<br />
* Learn why it's objectively [http://bitcoin.stackexchange.com/questions/305/what-are-the-perceived-advantages-of-bitcoin-as-a-means-of-exchange better as a means of exchange].<br />
* Get a [[Clients|client]] and try it out yourself.<br />
* Use an online wallet that you trust. (Examples: [[File:Coinkite.gif|20px|link=https://coinkite.com/promo/beginners]] [https://coinkite.com/promo/beginners Coinkite], [[File:Bci.gif|20px|link=https://blockchain.info/]] [https://blockchain.info/wallet/ BCI], [[File:Bitalo-favicon.png|link=https://bitalo.com]] [https://bitalo.com Bitalo])<br />
* Explore bitcoin with a [[:Category:Block chain browsers|block chain browser]] such as [https://www.biteasy.com Biteasy]<br />
* [http://bitcoin.stackexchange.com/ Ask questions]<br />
* [http://bitcoin.stackexchange.com/questions/118/how-much-bitcoin-will-i-mine-right-now-with-hardware-x Can I generate Free Money on my computer?] - TL;DR - Not really.<br />
* [https://en.bitcoin.it/wiki/FAQ Read the FAQ]<br />
* [[Buying Bitcoins (the noob version)|Where can I buy bitcoins?]] (Hint: [http://bitcoin.stackexchange.com/questions/2293/how-can-i-buy-bitcoin-via-a-credit-card-or-paypal You can't buy them with Paypal or credit cards])<br />
* Earn free bitcoins through [[Bonus_Programs|bonus programs]]<br />
<br />
If you're looking for how to get started with Bitcoin-Qt, [[Getting started installing bitcoin-qt|this is the article you're looking for]].<br />
<br />
==See Also==<br />
<br />
* [[Introduction|Bitcoin Introduction]]<br />
* [[Bonus_Programs|Bonus Programs]]<br />
* [[Trade|Bitcoin Businesses]]</div>Amincdhttps://en.bitcoin.it/w/index.php?title=Help:Getting_started&diff=45960Help:Getting started2014-04-05T22:30:16Z<p>Amincd: added trading in electronics as way to acquire bitcoin</p>
<hr />
<div>Here is a generic [[Bitcoin_Newbie_Guide|Getting Started guide]].<br />
* Get started buying bitcoins at [http://coinbase.com/ Coinbase]<br />
* Get free bitcoins and learn to use them in 5 minutes: [https://trybtc.com TryBTC]<br />
* If you have old electronics (iPhones, iPads, Androids, etc), you can trade them in for bitcoin at [Glyde](http://glyde.com/) or [Mintspare](https://www.mintspare.com/).<br />
* Start by watching [http://weusecoins.com/ this 2 minute vid].<br />
* Learn why it [http://bitcoin.stackexchange.com/questions/2834/what-are-the-perceived-advantages-of-bitcoin-as-a-store-of-value could be a good investment]<br />
* Learn why it's objectively [http://bitcoin.stackexchange.com/questions/305/what-are-the-perceived-advantages-of-bitcoin-as-a-means-of-exchange better as a means of exchange].<br />
* Get a [[Clients|client]] and try it out yourself.<br />
* Use an online wallet that you trust. (Examples: [[File:Coinkite.gif|20px|link=https://coinkite.com/promo/beginners]] [https://coinkite.com/promo/beginners Coinkite], [[File:Bci.gif|20px|link=https://blockchain.info/]] [https://blockchain.info/wallet/ BCI], [[File:Bitalo-favicon.png|link=https://bitalo.com]] [https://bitalo.com Bitalo])<br />
* Explore bitcoin with a [[:Category:Block chain browsers|block chain browser]] such as [https://www.biteasy.com Biteasy]<br />
* [http://bitcoin.stackexchange.com/ Ask questions]<br />
* [http://bitcoin.stackexchange.com/questions/118/how-much-bitcoin-will-i-mine-right-now-with-hardware-x Can I generate Free Money on my computer?] - TL;DR - Not really.<br />
* [https://en.bitcoin.it/wiki/FAQ Read the FAQ]<br />
* [[Buying Bitcoins (the noob version)|Where can I buy bitcoins?]] (Hint: [http://bitcoin.stackexchange.com/questions/2293/how-can-i-buy-bitcoin-via-a-credit-card-or-paypal You can't buy them with Paypal or credit cards])<br />
* Earn free bitcoins through [[Bonus_Programs|bonus programs]]<br />
<br />
If you're looking for how to get started with Bitcoin-Qt, [[Getting started installing bitcoin-qt|this is the article you're looking for]].<br />
<br />
==See Also==<br />
<br />
* [[Introduction|Bitcoin Introduction]]<br />
* [[Bonus_Programs|Bonus Programs]]<br />
* [[Trade|Bitcoin Businesses]]</div>Amincdhttps://en.bitcoin.it/w/index.php?title=Litecoin&diff=37442Litecoin2013-05-02T01:05:23Z<p>Amincd: </p>
<hr />
<div>== What is Litecoin? ==<br />
Litecoin is an alternative cryptocurrency based on Bitcoin. It differs from Bitcoin in that it targets a faster block rate (2.5 minutes) and uses scrypt for the primary hashing done in mining. MtGox announced in April 2013 that they would add support for Litecoin trading, a plan that was delayed due to recent DDOS attacks.<br />
<br />
While scrypt was claimed to be resistant to GPU-based mining early on, GPUs are currently the most efficient hardware with which to mine Litecoins.<br />
One of the aims of Litecoin was to provide a mining algorithm that did not compete with Bitcoin.<br />
<br />
In April 2013, Litecoin reached a market cap of $70 million and achieved a network strength above 12 gigahashes/second. This compares roughly to a network strength for Bitcoin of 12 terahashes/second.<br />
<br />
== Differences from Bitcoin ==<br />
<br />
==== Scrypt Proof of Work ====<br />
Litecoin uses scrypt as a proof-of-work scheme. Scrypt adds memory-intensive algorithms to reduce the efficiency of the kind of parallelization that GPUs offered in early Bitcoin mining. This led to Litecoin primarily being mined with CPUs at the beginning. CPU-based mining has been challenged by the appearance of more energy-efficient GPU-based mining around July/August of 2012 bringing a roughly ten-fold increase in network hashing strength. GPUs are currently the dominant Litecoin mining technology.<br />
<br />
Scrypt has been less widely used and analyzed than the SHA2 hashing algorithm used in Bitcoin, so there is some concern about possible weaknesses in its cryptographic scheme being discovered in the future.<br />
<br />
==== Faster Blocks ====<br />
The Litecoin blockchain differs from Bitcoin in that it generates blocks every 2.5 minutes on average (four times Bitcoin's rate).<br />
This means that merchants who accept transactions only 1 block deep get that confirmation quicker.<br />
However, it should be noted that more blocks are required to achieve the same amount of confirmation strength as Bitcoin (6 blocks of litecoin are not equivalent to 6 blocks of bitcoin).<br />
Unfortunately, this increases the number of hashes that are wasted in mining since miners will be working from the non-best block more of the time.<br />
<br />
==== 84 Million Litecoins ====<br />
Litecoin started with miners generating 50 coins per block as with Bitcoin, but to maintain Bitcoin's inflation rate chage schedule, the block reward gets halved every 840,000 blocks. As a result, the network is scheduled to produce a total of 84 million litecoins.<br />
<br />
==== Different Addresses ====<br />
<br />
Litecoin addresses start with L due to their version number. Otherwise, they are generated identically to Bitcoin addresses.<br />
<br />
==== (Slight) Premining ====<br />
Litecoin had two blocks premined, one more than the minimum single genesis block needed to start a block chain.<br />
<br />
==Criticism==<br />
==== Redundancy ====<br />
<!-- NOTE: scrypt is not a feature, since it is a flaw --><br />
Besides a faster first confirmation, Litecoin does not provide any other features over what Bitcoin provides.<br />
Because of this lack of innovation, some believe Litecoin is unlikely to match or surpass Bitcoin's value or user-base.<br />
It remains to be seen if the use of a different mining algorithm and faster block times add sufficient value for Litecoin's long-term survival.<br />
<br />
==== Not Silver to Gold ====<br />
Some argue that Litecoin cannot make sense as "silver to bitcoin's gold", because Bitcoin itself is both gold and silver:<br />
While in the long-run, the BTC unit may be too valuable for everyday trade ("gold"), there are other, much smaller [[units]] that can just as well serve the purpose of "silver" while being naturally/automatically "converted" to/from BTC.<br />
<br />
==== Vulnerability to mining monopoly ====<br />
<br />
Similarly to Bitcoin, Litecoin can be attacked by an entity that can match or exceed the hashrate of the network. Such a "51% attack" becomes more difficult to launch and maintain as the hash rate of the network grows. However, this argument posits that Litecoin is designed to be inefficient on all common computer components (both CPUs and GPUs) meaning that a malicious entity need only produce a small batch of specialized/custom hardware to overtake all the commodity mining systems combined.<br />
<br />
===== Memory bandwidth refutation =====<br />
Some attempt to refute this by arguing that scrypt is not designed to be inefficient, but is instead designed to be highly dependent on memory bandwidth.<br />
Since the high-speed cache RAM on modern processors already takes up most of the die space, no sizeable improvement could then be made by creating custom chips.<br />
If we accept this argument we then estimate the cost of attack utilizing GPUs that are avilable today. <br />
<br />
To do so we start with an estimated cost of hardware at $600 per megahashes per second and the March 14, 2013 Litecoin network hashrate of 2,500 megahashes per second.<br />
The total amount of equipment necessary to match and takeover the Litecoin network via 51% attack is then an estimated $1.5M USD (or about 5,000 AMD HD 5970s).<br />
There are tens of thousands of GPUs that are in the process of being made unprofitable for mining on the Bitcoin network ASICs.<br />
While these GPUs may be redeployed for Litecoin, a proportional and sustained rise of the Litecoin exchange rate would be required to support this additional GPU mining activity.<br />
<br />
==== Pump and Dump Scheme ====<br />
According to some, one or more of the aforementioned reasons imply that Litecoin has no future potential, and therefore effectively functions as a [http://www.investopedia.com/terms/p/pumpanddump.asp "pump and dump" scheme], rewarding those who get in sooner at the expense of those who adopt it just before it finally fails (and are left with nothing).<br />
<br />
Additionally, people often complain that the Litecoin community misrepresents it in other ways, such as portraying "faster block times" as if it makes transactions faster, and scrypt as if it is resistant to ASIC or FPGA hardware, in order to pretend Litecoin has value and inflate its value.<br />
<br />
It's important to note, generally these critics do not think that Litecoin/Blockchain currencies are pump and dump schemes "per se"; but rather that the existing network effect of Bitcoin, combined with the lack of meaningful differentiation between Litecoin and Bitcoin and Litecoin's adoption of a "designed to fail" proof-of-work algorithm; that Litecoin is bound to fail in the end. Bitcoin does not suffer from these "flaws" and therefore does not fall under the "pump and dump" scheme, according to this argument.<br />
<br />
==External links==<br />
*[http://litecoin.org/ Litecoin website]<br />
*[http://forum.litecoin.net Litecoin forum]<br />
*[http://explorer.litecoin.net/ Litecoin block explorer]<br />
*[http://www.ltc-charts.com/ Charts]<br />
*[http://litecoinscout.com/static/ Litecoin network graphs]<br />
*[https://github.com/litecoin-project/litecoin/wiki Litecoin wiki]<br />
*[https://www.litecoinglobal.com Litecoin Global Exchange (virtual stock exchange)]<br />
*[http://www.crypto.st Crypto Street - Advanced Trading Exchange for Litecoins]<br />
*[http://www.technologyreview.com/news/513661/bitcoin-isnt-the-only-cryptocurrency-in-town/ MIT Technology Review: Bitcoin Isn't the only Cryptocurrency in Town]<br />
<br />
==See also==<br />
[[Cryptocoin]]<br />
<br />
[[Category:Alternative cryptocurrencies]]<br />
[[Category:Digital currencies]]</div>Amincdhttps://en.bitcoin.it/w/index.php?title=Litecoin&diff=37097Litecoin2013-04-17T18:25:09Z<p>Amincd: /* Scrypt Proof of Work */</p>
<hr />
<div>== What is Litecoin? ==<br />
Litecoin is an alternative cryptocurrency based on Bitcoin. It differs from Bitcoin in that it targets a faster block rate (2.5 minutes) and uses scrypt for the primary hashing done in mining. <br />
<br />
While scrypt was claimed to be resistant to GPU-based mining early on, GPUs are currently the most efficient hardware with which to mine Litecoins.<br />
One of the aims of Litecoin was to provide a mining algorithm that did not compete with Bitcoin.<br />
<br />
In March 2013, Litecoin reached a market cap of $10 million and achieved a network strength above two gigahashes/second. This compares roughly to a network strength for Bitcoin of two terahashes/second.<br />
<br />
== Differences from Bitcoin ==<br />
<br />
==== Scrypt Proof of Work ====<br />
Litecoin uses scrypt as a proof-of-work scheme. Scrypt adds memory-intensive algorithms to reduce the efficiency of the kind of parallelization that GPUs offered in early Bitcoin mining. This led to Litecoin primarily being mined with CPUs at the beginning. CPU-based mining has been challenged by the appearance of more energy-efficient GPU-based mining around July/August of 2012 bringing a roughly ten-fold increase in network hashing strength. GPUs are currently the dominant Litecoin mining technology.<br />
<br />
Scrypt has been less widely used and analyzed than the SHA2 hashing algorithm used in bitcoin, so there is some concern about possible weaknesses in its cryptographic scheme being discovered in the future.<br />
<br />
==== Faster Blocks ====<br />
The Litecoin blockchain differs from Bitcoin in that it generates blocks every 2.5 minutes on average (four times Bitcoin's rate).<br />
This means that merchants who accept transactions only 1 block deep get that confirmation quicker.<br />
However, it should be noted that more blocks are required to achieve the same amount of confirmation strength as Bitcoin (6 blocks of litecoin are not equivalent to 6 blocks of bitcoin).<br />
Unfortunately, this increases the number of hashes that are wasted in mining since miners will working from the non-best block more of the time.<br />
<br />
==== 84 Million Litecoins ====<br />
Litecoin started with miners generating 50 coins per block as with Bitcoin, but to maintain Bitcoin's inflation rate chage schedule, the block reward gets halved every 840,000 blocks. As a result, the network is scheduled to produce a total of 84 million litecoins.<br />
<br />
==== Different Addresses ====<br />
<br />
Litecoin addresses start with L due to their version number. Otherwise, they are generated identically to Bitcoin addresses.<br />
<br />
==== (Slight) Premining ====<br />
Litecoin had two blocks premined, one more than the minimum single genesis block needed to start a block chain.<br />
<br />
==Criticism==<br />
==== Redundancy ====<br />
<!-- NOTE: scrypt is not a feature, since it is a flaw --><br />
Besides a faster first confirmation, Litecoin does not provide any other features over what Bitcoin provides.<br />
Because of this lack of innovation, some believe Litecoin is unlikely to match or surpass Bitcoin's value or user-base.<br />
It remains to be seen if the use of a different mining algorithm and faster block times add sufficient value for Litecoin's long-term survival.<br />
<br />
==== Not Silver to Gold ====<br />
Some argue that Litecoin cannot make sense as "silver to bitcoin's gold", because Bitcoin itself is both gold and silver:<br />
While in the long-run, the BTC unit may be too valuable for everyday trade ("gold"), there are other, much smaller [[units]] that can just as well serve the purpose of "silver" while being naturally/automatically "converted" to/from BTC.<br />
<br />
==== Vulnerability to mining monopoly ====<br />
<br />
Similarly to Bitcoin, Litecoin can be attacked by an entity that can match or exceed the hashrate of the network. Such a "51% attack" becomes more difficult to launch and maintain as the hash rate of the network grows. However, this argument posits that Litecoin is designed to be inefficient on all common computer components (both CPUs and GPUs) meaning that a malicious entity need only produce a small batch of specialized/custom hardware to overtake all the commodity mining systems combined.<br />
<br />
===== Memory bandwidth refutation =====<br />
This may be refuted by arguing that scrypt is not designed to be inefficient, but is instead designed to be highly dependent on memory bandwidth.<br />
Since the high-speed cache RAM on modern processors already takes up most of the die space, no sizeable improvement could then be made by creating custom chips.<br />
If we accept this argument we then estimate the cost of attack utilizing GPUs that are avilable today. <br />
<br />
To do so we start with an estimated cost of hardware at $600 per megahashes per second and the March 14, 2013 Litecoin network hashrate of 2,500 megahashes per second.<br />
The total amount of equipment necessary to match and takeover the Litecoin network via 51% attack is then an estimated $1.5M USD (or about 5,000 AMD HD 5970s).<br />
There are tens of thousands of GPUs that are in the process of being made unprofitable for mining on the Bitcoin network ASICs.<br />
While these GPUs may be redeployed for Litecoin, a proportional and sustained rise of the Litecoin exchange rate would be required to support this additional GPU mining activity.<br />
<br />
==== Pump and Dump Scheme ====<br />
According to some, one or more of the aforementioned reasons imply that Litecoin has no future potential, and therefore effectively functions as a [http://www.investopedia.com/terms/p/pumpanddump.asp "pump and dump" scheme], rewarding those who get in sooner at the expense of those who adopt it just before it finally fails (and are left with nothing).<br />
<br />
Additionally, people often complain that the Litecoin community misrepresents it in other ways, such as portraying "faster block times" as if it makes transactions faster, and scrypt as if it is resistant to ASIC or FPGA hardware, in order to pretend Litecoin has value and inflate its value.<br />
<br />
It's important to note, generally these critics do not think that Litecoin/Blockchain currencies are pump and dump schemes "per se"; but rather that the existing network effect of Bitcoin, combined with the lack of meaningful differentiation between Litecoin and Bitcoin and Litecoin's adoption of a "designed to fail" proof-of-work algorithm; that Litecoin is bound to fail in the end. Bitcoin does not suffer from these "flaws" and therefore does not fall under the "pump and dump" scheme, according to this argument.<br />
<br />
==External links==<br />
*[http://litecoin.org/ Litecoin website]<br />
*[http://forum.litecoin.net Litecoin forum]<br />
*[http://explorer.litecoin.net/ Litecoin block explorer]<br />
*[http://www.ltc-charts.com/ Charts]<br />
*[http://litecoinscout.com/static/ Litecoin network graphs]<br />
*[https://github.com/litecoin-project/litecoin/wiki Litecoin wiki]<br />
*[https://www.litecoinglobal.com Litecoin Global Exchange (virtual stock exchange)]<br />
<br />
==See also==<br />
[[Cryptocoin]]<br />
<br />
[[Category:Alternative cryptocurrencies]]<br />
[[Category:Digital currencies]]</div>Amincdhttps://en.bitcoin.it/w/index.php?title=Litecoin&diff=37096Litecoin2013-04-17T18:24:46Z<p>Amincd: /* Scrypt Proof of Work */</p>
<hr />
<div>== What is Litecoin? ==<br />
Litecoin is an alternative cryptocurrency based on Bitcoin. It differs from Bitcoin in that it targets a faster block rate (2.5 minutes) and uses scrypt for the primary hashing done in mining. <br />
<br />
While scrypt was claimed to be resistant to GPU-based mining early on, GPUs are currently the most efficient hardware with which to mine Litecoins.<br />
One of the aims of Litecoin was to provide a mining algorithm that did not compete with Bitcoin.<br />
<br />
In March 2013, Litecoin reached a market cap of $10 million and achieved a network strength above two gigahashes/second. This compares roughly to a network strength for Bitcoin of two terahashes/second.<br />
<br />
== Differences from Bitcoin ==<br />
<br />
==== Scrypt Proof of Work ====<br />
Litecoin uses scrypt as a proof-of-work scheme. Scrypt adds memory-intensive algorithms to reduce the efficiency of the kind of parallelization that GPUs offered in early Bitcoin mining. This led to Litecoin primarily being mined with CPUs at the beginning. CPU-based mining has been challenged by the appearance of more energy-efficient GPU-based mining around July/August of 2012 bringing a roughly ten-fold increase in network hashing strength. GPUs are currently the dominant Litecoin mining technology.<br />
<br />
Scrypt has been less widely used and tested than the SHA2 hashing algorithm used in bitcoin, so there is some concern about possible weaknesses in its cryptographic scheme being discovered in the future.<br />
<br />
==== Faster Blocks ====<br />
The Litecoin blockchain differs from Bitcoin in that it generates blocks every 2.5 minutes on average (four times Bitcoin's rate).<br />
This means that merchants who accept transactions only 1 block deep get that confirmation quicker.<br />
However, it should be noted that more blocks are required to achieve the same amount of confirmation strength as Bitcoin (6 blocks of litecoin are not equivalent to 6 blocks of bitcoin).<br />
Unfortunately, this increases the number of hashes that are wasted in mining since miners will working from the non-best block more of the time.<br />
<br />
==== 84 Million Litecoins ====<br />
Litecoin started with miners generating 50 coins per block as with Bitcoin, but to maintain Bitcoin's inflation rate chage schedule, the block reward gets halved every 840,000 blocks. As a result, the network is scheduled to produce a total of 84 million litecoins.<br />
<br />
==== Different Addresses ====<br />
<br />
Litecoin addresses start with L due to their version number. Otherwise, they are generated identically to Bitcoin addresses.<br />
<br />
==== (Slight) Premining ====<br />
Litecoin had two blocks premined, one more than the minimum single genesis block needed to start a block chain.<br />
<br />
==Criticism==<br />
==== Redundancy ====<br />
<!-- NOTE: scrypt is not a feature, since it is a flaw --><br />
Besides a faster first confirmation, Litecoin does not provide any other features over what Bitcoin provides.<br />
Because of this lack of innovation, some believe Litecoin is unlikely to match or surpass Bitcoin's value or user-base.<br />
It remains to be seen if the use of a different mining algorithm and faster block times add sufficient value for Litecoin's long-term survival.<br />
<br />
==== Not Silver to Gold ====<br />
Some argue that Litecoin cannot make sense as "silver to bitcoin's gold", because Bitcoin itself is both gold and silver:<br />
While in the long-run, the BTC unit may be too valuable for everyday trade ("gold"), there are other, much smaller [[units]] that can just as well serve the purpose of "silver" while being naturally/automatically "converted" to/from BTC.<br />
<br />
==== Vulnerability to mining monopoly ====<br />
<br />
Similarly to Bitcoin, Litecoin can be attacked by an entity that can match or exceed the hashrate of the network. Such a "51% attack" becomes more difficult to launch and maintain as the hash rate of the network grows. However, this argument posits that Litecoin is designed to be inefficient on all common computer components (both CPUs and GPUs) meaning that a malicious entity need only produce a small batch of specialized/custom hardware to overtake all the commodity mining systems combined.<br />
<br />
===== Memory bandwidth refutation =====<br />
This may be refuted by arguing that scrypt is not designed to be inefficient, but is instead designed to be highly dependent on memory bandwidth.<br />
Since the high-speed cache RAM on modern processors already takes up most of the die space, no sizeable improvement could then be made by creating custom chips.<br />
If we accept this argument we then estimate the cost of attack utilizing GPUs that are avilable today. <br />
<br />
To do so we start with an estimated cost of hardware at $600 per megahashes per second and the March 14, 2013 Litecoin network hashrate of 2,500 megahashes per second.<br />
The total amount of equipment necessary to match and takeover the Litecoin network via 51% attack is then an estimated $1.5M USD (or about 5,000 AMD HD 5970s).<br />
There are tens of thousands of GPUs that are in the process of being made unprofitable for mining on the Bitcoin network ASICs.<br />
While these GPUs may be redeployed for Litecoin, a proportional and sustained rise of the Litecoin exchange rate would be required to support this additional GPU mining activity.<br />
<br />
==== Pump and Dump Scheme ====<br />
According to some, one or more of the aforementioned reasons imply that Litecoin has no future potential, and therefore effectively functions as a [http://www.investopedia.com/terms/p/pumpanddump.asp "pump and dump" scheme], rewarding those who get in sooner at the expense of those who adopt it just before it finally fails (and are left with nothing).<br />
<br />
Additionally, people often complain that the Litecoin community misrepresents it in other ways, such as portraying "faster block times" as if it makes transactions faster, and scrypt as if it is resistant to ASIC or FPGA hardware, in order to pretend Litecoin has value and inflate its value.<br />
<br />
It's important to note, generally these critics do not think that Litecoin/Blockchain currencies are pump and dump schemes "per se"; but rather that the existing network effect of Bitcoin, combined with the lack of meaningful differentiation between Litecoin and Bitcoin and Litecoin's adoption of a "designed to fail" proof-of-work algorithm; that Litecoin is bound to fail in the end. Bitcoin does not suffer from these "flaws" and therefore does not fall under the "pump and dump" scheme, according to this argument.<br />
<br />
==External links==<br />
*[http://litecoin.org/ Litecoin website]<br />
*[http://forum.litecoin.net Litecoin forum]<br />
*[http://explorer.litecoin.net/ Litecoin block explorer]<br />
*[http://www.ltc-charts.com/ Charts]<br />
*[http://litecoinscout.com/static/ Litecoin network graphs]<br />
*[https://github.com/litecoin-project/litecoin/wiki Litecoin wiki]<br />
*[https://www.litecoinglobal.com Litecoin Global Exchange (virtual stock exchange)]<br />
<br />
==See also==<br />
[[Cryptocoin]]<br />
<br />
[[Category:Alternative cryptocurrencies]]<br />
[[Category:Digital currencies]]</div>Amincdhttps://en.bitcoin.it/w/index.php?title=Litecoin&diff=37095Litecoin2013-04-17T18:14:32Z<p>Amincd: /* What is Litecoin? */</p>
<hr />
<div>== What is Litecoin? ==<br />
Litecoin is an alternative cryptocurrency based on Bitcoin. It differs from Bitcoin in that it targets a faster block rate (2.5 minutes) and uses scrypt for the primary hashing done in mining. <br />
<br />
While scrypt was claimed to be resistant to GPU-based mining early on, GPUs are currently the most efficient hardware with which to mine Litecoins.<br />
One of the aims of Litecoin was to provide a mining algorithm that did not compete with Bitcoin.<br />
<br />
In March 2013, Litecoin reached a market cap of $10 million and achieved a network strength above two gigahashes/second. This compares roughly to a network strength for Bitcoin of two terahashes/second.<br />
<br />
== Differences from Bitcoin ==<br />
<br />
==== Scrypt Proof of Work ====<br />
Litecoin uses scrypt as a proof-of-work scheme. Scrypt adds memory-intensive algorithms to reduce the efficiency of the kind of parallelization that GPUs offered in early Bitcoin mining. This led to Litecoin primarily being mined with CPUs at the beginning. CPU-based mining has been challenged by the appearance of more energy-efficient GPU-based mining around July/August of 2012 bringing a roughly ten-fold increase in network hashing strength. GPUs are currently the dominant Litecoin mining technology.<br />
<br />
==== Faster Blocks ====<br />
The Litecoin blockchain differs from Bitcoin in that it generates blocks every 2.5 minutes on average (four times Bitcoin's rate).<br />
This means that merchants who accept transactions only 1 block deep get that confirmation quicker.<br />
However, it should be noted that more blocks are required to achieve the same amount of confirmation strength as Bitcoin (6 blocks of litecoin are not equivalent to 6 blocks of bitcoin).<br />
Unfortunately, this increases the number of hashes that are wasted in mining since miners will working from the non-best block more of the time.<br />
<br />
==== 84 Million Litecoins ====<br />
Litecoin started with miners generating 50 coins per block as with Bitcoin, but to maintain Bitcoin's inflation rate chage schedule, the block reward gets halved every 840,000 blocks. As a result, the network is scheduled to produce a total of 84 million litecoins.<br />
<br />
==== Different Addresses ====<br />
<br />
Litecoin addresses start with L due to their version number. Otherwise, they are generated identically to Bitcoin addresses.<br />
<br />
==== (Slight) Premining ====<br />
Litecoin had two blocks premined, one more than the minimum single genesis block needed to start a block chain.<br />
<br />
==Criticism==<br />
==== Redundancy ====<br />
<!-- NOTE: scrypt is not a feature, since it is a flaw --><br />
Besides a faster first confirmation, Litecoin does not provide any other features over what Bitcoin provides.<br />
Because of this lack of innovation, some believe Litecoin is unlikely to match or surpass Bitcoin's value or user-base.<br />
It remains to be seen if the use of a different mining algorithm and faster block times add sufficient value for Litecoin's long-term survival.<br />
<br />
==== Not Silver to Gold ====<br />
Some argue that Litecoin cannot make sense as "silver to bitcoin's gold", because Bitcoin itself is both gold and silver:<br />
While in the long-run, the BTC unit may be too valuable for everyday trade ("gold"), there are other, much smaller [[units]] that can just as well serve the purpose of "silver" while being naturally/automatically "converted" to/from BTC.<br />
<br />
==== Vulnerability to mining monopoly ====<br />
<br />
Similarly to Bitcoin, Litecoin can be attacked by an entity that can match or exceed the hashrate of the network. Such a "51% attack" becomes more difficult to launch and maintain as the hash rate of the network grows. However, this argument posits that Litecoin is designed to be inefficient on all common computer components (both CPUs and GPUs) meaning that a malicious entity need only produce a small batch of specialized/custom hardware to overtake all the commodity mining systems combined.<br />
<br />
===== Memory bandwidth refutation =====<br />
This may be refuted by arguing that scrypt is not designed to be inefficient, but is instead designed to be highly dependent on memory bandwidth.<br />
Since the high-speed cache RAM on modern processors already takes up most of the die space, no sizeable improvement could then be made by creating custom chips.<br />
If we accept this argument we then estimate the cost of attack utilizing GPUs that are avilable today. <br />
<br />
To do so we start with an estimated cost of hardware at $600 per megahashes per second and the March 14, 2013 Litecoin network hashrate of 2,500 megahashes per second.<br />
The total amount of equipment necessary to match and takeover the Litecoin network via 51% attack is then an estimated $1.5M USD (or about 5,000 AMD HD 5970s).<br />
There are tens of thousands of GPUs that are in the process of being made unprofitable for mining on the Bitcoin network ASICs.<br />
While these GPUs may be redeployed for Litecoin, a proportional and sustained rise of the Litecoin exchange rate would be required to support this additional GPU mining activity.<br />
<br />
==== Pump and Dump Scheme ====<br />
According to some, one or more of the aforementioned reasons imply that Litecoin has no future potential, and therefore effectively functions as a [http://www.investopedia.com/terms/p/pumpanddump.asp "pump and dump" scheme], rewarding those who get in sooner at the expense of those who adopt it just before it finally fails (and are left with nothing).<br />
<br />
Additionally, people often complain that the Litecoin community misrepresents it in other ways, such as portraying "faster block times" as if it makes transactions faster, and scrypt as if it is resistant to ASIC or FPGA hardware, in order to pretend Litecoin has value and inflate its value.<br />
<br />
It's important to note, generally these critics do not think that Litecoin/Blockchain currencies are pump and dump schemes "per se"; but rather that the existing network effect of Bitcoin, combined with the lack of meaningful differentiation between Litecoin and Bitcoin and Litecoin's adoption of a "designed to fail" proof-of-work algorithm; that Litecoin is bound to fail in the end. Bitcoin does not suffer from these "flaws" and therefore does not fall under the "pump and dump" scheme, according to this argument.<br />
<br />
==External links==<br />
*[http://litecoin.org/ Litecoin website]<br />
*[http://forum.litecoin.net Litecoin forum]<br />
*[http://explorer.litecoin.net/ Litecoin block explorer]<br />
*[http://www.ltc-charts.com/ Charts]<br />
*[http://litecoinscout.com/static/ Litecoin network graphs]<br />
*[https://github.com/litecoin-project/litecoin/wiki Litecoin wiki]<br />
*[https://www.litecoinglobal.com Litecoin Global Exchange (virtual stock exchange)]<br />
<br />
==See also==<br />
[[Cryptocoin]]<br />
<br />
[[Category:Alternative cryptocurrencies]]<br />
[[Category:Digital currencies]]</div>Amincdhttps://en.bitcoin.it/w/index.php?title=Satoshi_Nakamoto&diff=36507Satoshi Nakamoto2013-03-31T08:26:21Z<p>Amincd: /* Identity */</p>
<hr />
<div>'''Satoshi Nakamoto''' is the pseudonymous person or group of people who designed and created the original [[Bitcoin]] software, currently known as [[Bitcoin-Qt]].<br />
<br />
His involvement in the original [[Bitcoin]] software does not appear to extend past mid-2010.<br />
<br />
==Identity==<br />
<br />
There are no records of Nakamoto's identity or identities prior to the creation of [[Bitcoin]]. On his [[P2P foundation]] profile, Nakamoto claimed to be an individual male at the age of 37 and living in Japan, which was met with great skepticism due to his use of English and his Bitcoin [[software]] not being documented nor labeled in Japanese.<br />
<br />
British formatting in his written work implies Nakamoto is of British origin. However, he also sometimes used American spelling, which may indicate that he was intentionally trying (but failed) to mask his writing style, or that he is more than one person.<br />
<br />
The first release of his original [[Bitcoin]] software is speculated to be of a collabrative effort, leading some to claim that Satoshi Nakamoto was a collective pseudonym for a group of people.<br />
<br />
==Work==<br />
<br />
Nakamoto has claimed that he has been working on Bitcoin since 2007. In 2008, he published a paper on The Cryptography Mailing List at metzdowd.com describing the Bitcoin digital currency. In 2009, he released the first [[Bitcoin]] software that launched the network and the first units of the Bitcoin [[currency]].<br />
<br />
Version 0.1 was for Windows only and had no command-line interface. It was compiled using Microsoft Visual Studio. The code was elegant in some ways and inelegant in others. The code does not appear to have been written by either a total amateur or a professional programmer; some people speculate based on this that Satoshi was an academic with a lot of theoretical knowledge but not much programming experience. Version 0.1 was remarkably complete. If Satoshi truly only worked on it alone for two years, he must have spent a massive amount of time on the project.<br />
<br />
Nakamoto was active in making modifications to the Bitcoin software and posting technical information on the [[Bitcoin Forum]] until his contact with other Bitcoin developers and the community gradually began to fade in mid-2010. Until a few months before he left, almost all modifications to the source code were done by Satoshi -- he accepted contributions relatively rarely. Just before he left, he set up [[Gavin Andresen]] as his successor by giving him access to the Bitcoin SourceForge project and a copy of the [[Alerts|alert key]].<br />
<br />
==Motives==<br />
<br />
Nakamoto's work appears to be politically motivated, as quoted:<br />
<br />
"Yes, [we will not find a solution to political problems in cryptography,] but we can win a major battle in the arms race and gain a new territory of freedom for several years. Governments are good at cutting off the heads of a centrally controlled networks like Napster, but pure P2P networks like Gnutella and Tor seem to be holding their own." - Satoshi Nakamoto<br />
<br />
"[Bitcoin is] very attractive to the libertarian viewpoint if we can explain it properly. I'm better with code than with words though." - Satoshi Nakamoto<br />
<br />
In the Bitcoin network's transaction database, the original entry has a note by Nakamoto that reads as:<br />
<br />
"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks"<br />
<br />
Some claim this quote implies Nakamoto had great concern or contempt for the current [[central banking]] system.<br />
<br />
==Influence==<br />
The smallest unit of the [[Bitcoin]] currency (1/100,000,000) has been named "satoshi" in collective homage to his founding of [[Bitcoin]].<br />
<br />
==References==<br />
*[http://bitcoin.org/bitcoin.pdf Bitcoin: A Peer-to-Peer Electronic Cash System by Satoshi Nakamoto]<br />
*[http://www.wired.com/magazine/2011/11/mf_bitcoin/ The Rise and Fall of Bitcoin]<br />
*[http://betabeat.com/2011/10/did-the-new-yorkers-joshua-davis-nail-the-identity-of-bitcoin-creator-satoshi-nakamoto/ The New Yorker’s Joshua Davis Attempts to Identify Bitcoin Creator Satoshi Nakamoto]<br />
*[http://www.newyorker.com/reporting/2011/10/10/111010fa_fact_davis The Crypto-Currency: Bitcoin and its mysterious inventor]<br />
*[http://www.fastcompany.com/1785445/bitcoin-crypto-currency-mystery-reopened The Bitcoin Crypto-Currency Mystery Reopened]<br />
*[http://www.mail-archive.com/search?l=cryptography@metzdowd.com&q=from:%22Satoshi+Nakamoto%22 Satoshi's posts to Cryptography mailing list]<br />
<br />
<br />
[[Category:Pseudonyms]]<br />
[[de:Satoshi Nakamoto]]<br />
[[es:Satoshi Nakamoto]]<br />
<br />
[[Category:Individuals]]</div>Amincdhttps://en.bitcoin.it/w/index.php?title=Help:FAQ&diff=36232Help:FAQ2013-03-20T06:40:22Z<p>Amincd: /* How does the peer finding mechanism work? */ fixed typo</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 [[physical bitcoins]], but ultimately, a bitcoin is just a number associated with a [[Address|Bitcoin Address]]. A physical 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_(the_noob_version)|trade them]] for traditional currency.<br />
* Find someone to trade cash for bitcoins in-person through a [https://en.bitcoin.it/wiki/Category:Directories local directory].<br />
* Participate in a [[Pooled mining|mining pool]].<br />
* If you have a lot of mining hardware, you can solo mine and attempt to create a new [[block]] (currently yields 25 bitcoins plus transaction fees).<br />
<br />
===Does Bitcoin guarantee an influx of free money?===<br />
<br />
Since Bitcoin is a new technology, what it is and how it works may be initially unclear. Bitcoin is sometimes presented as being one of three things:<br />
<ol style="list-style-type: upper-alpha;"><br />
<li>Some sort of online 'get-rich-quick' scam.</li><br />
<li>A loophole in the market economy, the installation of which guarantees a steady influx of cash.</li><br />
<li>A sure investment that will almost certainly yield a profit.</li><br />
</ol><br />
In fact, none of the above are true. Let's look at them independently.<br />
<br />
;Is Bitcoin a 'get-rich-quick' scheme?<br />
:If you've spent much time on the Internet, you've probably seen ads for many 'get-rich-quick' schemes. These ads usually promise huge profits for a small amounts of easy work. Such schemes are usually pyramid/matrix-style schemes that make money from their own employees and offer nothing of any real value. Most convince one to buy packages that will make them earn hundreds a day, which in fact have the buyer distribute more such ads, and make minute profits.<br />
<br />
:Bitcoin is in no way similar to these schemes. Bitcoin doesn't promise windfall profits. There is no way for the developers to make money from your involvement or to take money from you. That bitcoins are nearly impossible to acquire without the owner's consent represents one of its greatest strengths. Bitcoin is an experimental, virtual currency that may succeed or may fail. None of its developers expect to get rich off of it. <br />
<br />
:A more detailed answer to this question can be found [http://bitcointalk.org/?topic=7815.0 here].<br />
<br />
;Will I make money by installing the client?<br />
:Most people who use Bitcoin don't earn anything by doing so, and the default client has no built-in way to earn Bitcoins. A small minority of people with dedicated, high-performance hardware do earn some Bitcoins by "''mining''" (generating new bitcoins, see [[#What is mining?|What is mining?]]) with special software, but joining Bitcoin shouldn't be construed as being the road to riches. Most Bitcoin users get involved because they find the project conceptually interesting and don't earn anything by doing so. This is also why you won't find much speculation about the political or economic repercussions of Bitcoin anywhere on this site: Bitcoin developers owe their dedication to the project's intellectual yieldings more than to those of a monetary nature. Bitcoin is still taking its first baby steps; it may go on to do great things but right now it only has something to offer those chasing conceptually interesting projects or bleeding edge technology.<br />
<br />
;As an investment, is Bitcoin a sure thing?<br />
:Bitcoin is a new and interesting electronic currency, the value of which is not backed by any single government or organization. Like other currencies, it is worth something partly because people are willing to trade it for goods and services. Its exchange rate fluctuates continuously, and sometimes wildly. It lacks wide acceptance and is vulnerable to manipulation by parties with modest funding. Security incidents such as website and account compromise may trigger major sell-offs. Other fluctuations can build into positive feedback loops cause much larger exchange rate fluctuations. Anyone who puts money into Bitcoin should take measures to reduce their risk and consider it as a high-risk currency. Later, as Bitcoin becomes better known and more widely accepted, it should stabilize, but for the time being it is unpredictable. Any investment in Bitcoin should be done carefully and with a clear plan to manage risk.<br />
<br />
=== Can I buy bitcoins with Paypal? ===<br />
<br />
It is possible to buy [[physical bitcoins]] with PayPal but it is otherwise difficult and/or expensive to do so, because of significant risk to the seller. <br />
<br />
While it is possible to find an individual who wishes to sell Bitcoin to you via Paypal, (perhaps via [http://www.bitcoin-otc.com/ #bitcoin-otc] ) most 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 purchase. PayPal often sides with the fraudulent buyer in this case which means any seller would need to cover that risk with higher fees or refuse to accept PayPal altogether.<br />
<br />
Buying Bitcoins from individuals with this method is still possible, but requires the seller to have some trust that the buyer will not file a claim with PayPal to reverse the payment.<br />
<br />
=== Where can I find a forum to discuss Bitcoin? ===<br />
<br />
Please visit the [[Bitcoin:Community_portal#Bitcoin_Community_Forums_on_various_platforms|Community Portal]] for links to Bitcoin-related 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 bitcoins are generated by the network through the process of "[[#What is mining?|''mining'']]". In a process that is similar to a continuous raffle draw, mining nodes on the network are awarded bitcoins each time they find the solution to a certain mathematical problem (and thereby create a new [[block]]). Creating a block is a [[proof of work]] with a difficulty that varies with the overall strength of the network. The reward for solving a block is [[Controlled Currency Supply|automatically adjusted]] so that in roughly the first four years of operation of the Bitcoin network, {{formatnum:10500000}} BTC will be created. This amount is halved each four years, so it will be {{formatnum:5250000}} over years 4-8, {{formatnum:2625000}} over years 8-12, and so on. Thus the total number of bitcoins in existence will not exceed {{formatnum:21000000}}. See [[Controlled Currency Supply]].<br />
<br />
Blocks are [[Mining|mined]] every 10 minutes, on average and for the first four years ({{formatnum:210000}} blocks) each block includes 50 new bitcoins. As the amount of processing power directed at mining changes, the difficulty of creating new bitcoins changes. This difficulty factor is calculated every 2016 blocks and is based upon the time taken to generate the previous 2016 blocks. See [[Mining]].<br />
<br />
=== What's the current total number of bitcoins in existence? ===<br />
<br />
[http://blockexplorer.com/q/totalbc Current count]. Also see [https://blockchain.info/charts/total-bitcoins Total bitcoins in circulation chart]<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 {{formatnum:210000}} blocks, 25 BTC for the next {{formatnum:210000}} blocks, then 12.5 BTC, 6.25 BTC and so on.<br />
<br />
=== How divisible are bitcoins? ===<br />
<br />
A bitcoin can be divided down to 8 decimal places. Therefore, 0.00000001 BTC is the smallest amount that can be handled in a transaction. If necessary, the protocol and related software can be modified to handle even smaller amounts.<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 centibitcoin (also referred to as bitcent)<br />
* 0.001 BTC = 1 mBTC = 1 millibitcoin (also referred to as mbit (pronounced em-bit) or millibit or even bitmill)<br />
* 0.000 001 BTC = 1 μBTC = 1 microbitcoin (also referred to as ubit (pronounced yu-bit) or microbit)<br />
<br />
The above follows the accepted international SI prefixes for hundredths, thousandths, and millionths. 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 />
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 />
* [https://bitcointalk.org/index.php?topic=14438.msg195287#msg195287 We need names]<br />
* [https://bitcointalk.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 />
Eventually the reward will go from 0.00000001 BTC to zero and no more bitcoins will be created. <br />
<br />
The block reward calculation is done as a right bitwise shift of a 64-bit signed integer, which means it is divided by two and rounded down. The integer is equal to the value in BTC * 100,000,000 since internally in the reference client software, all Bitcoin balances and values are stored as unsigned integers.<br />
<br />
With an initial block reward of 50 BTC, it will take many 4-year periods for the block reward to reach zero.<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 which should be generated at or near the year 2140. The total number of coins in circulation will then 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 20,999,999.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, these fees will sustain the ability to use bitcoins and the Bitcoin network. There is no practical limit on the number of blocks that will be mined in the future.<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 eventually 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 single high end server by todays standards). It is 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 useful and because they are [[Controlled Currency Supply|scarce]]. As they are accepted by more merchants, their value will [http://en.wikipedia.org/wiki/Sticky_%28economics%29 stabilize]. 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. Bitcoins, like dollars and euros, are not backed up by anything except the variety of merchants that accept them.<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 />
Alternatively it needs to be added that while the law of supply and demand applies it does not guarantee value of Bitcoins in the future. If confidence in Bitcoins is lost then it will not matter that the supply can no longer be increased, the demand will fall off with all holders trying to get rid of their coins. An example of this can be seen in cases of state currencies, in cases when the state in question dissolves and so no new supply of the currency is available (the central authority managing the supply is gone), however the demand for the currency falls sharply because confidence in its purchasing power disappears. Of-course Bitcoins do not have such central authority managing the supply of the coins, but it does not prevent confidence from eroding due to other situations that are not necessarily predictable.<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 have no inherent value. 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 />
=== 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, and indeed, society as a whole, benefit from the usefulness of a stable, fast, inexpensive, and widely accepted p2p currency.<br />
<br />
The fact that early adopters benefit more doesn't alone make anything a Ponzi scheme. All good investments in successful companies have this quality.<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 />
Since the pricing of Bitcoins has fallen greatly from its June 2011 peak, prices today are much more similar to those enjoyed by many early adopters. Those who are buying Bitcoins today likely believe that Bitcoin will grow significantly in the future. Setting aside the brief opportunity to have sold Bitcoins at the June 2011 peak enjoyed by few, the early-adopter window is arguably still open.<br />
<br />
===Won't loss of wallets and the finite amount of Bitcoins create excessive deflation, destroying Bitcoin? ===<br />
Worries about Bitcoin being destroyed by deflation are not entirely unfounded. Unlike most currencies, which experience inflation as their founding institutions create more and more units, Bitcoin will likely experience gradual deflation with the passage of time. Bitcoin is unique in that only a small amount of units will ever be produced (twenty-one million to be exact), this number has been known since the project's inception, and the units are created at a predicable rate.<br />
<br />
Also, Bitcoin users are faced with a danger that doesn't threaten users of any other currency: if a Bitcoin user loses his wallet, his money is gone forever, unless he finds it again. And not just to him; it's gone completely out of circulation, rendered utterly inaccessible to anyone. As people will lose their wallets, the total number of Bitcoins will slowly decrease.<br />
<br />
Therefore, Bitcoin seems to be faced with a unique problem. Whereas most currencies inflate over time, Bitcoin will mostly likely do the just the opposite. Time will see the irretrievable loss of an ever-increasing number of Bitcoins. An already small number will be permanently whittled down further and further. And as there become fewer and fewer Bitcoins, the laws of supply and demand suggest that their value will probably continually rise.<br />
<br />
Thus Bitcoin is bound to once again stray into mysterious territory, because no one exactly knows what happens to a currency that grows continually more valuable. Economists generally agree that a low level of inflation is a good thing for a currency, but nobody is quite sure about what might happens to one that continually deflates. Although deflation could hardly be called a rare phenomenon, steady, constant deflation is unheard of. There may be a lot of speculation, no one has any hard data to back up their claims.<br />
<br />
That being said, there is a mechanism in place to combat the obvious consequences. Extreme deflation would render most currencies highly impractical: if a single Canadian dollar could suddenly buy the holder a car, how would one go about buying bread or candy? Even pennies would fetch more than a person could carry. Bitcoin, however, offers a simple and stylish solution: infinite divisibility. Bitcoins can be divided up and trade into as small of pieces as one wants, so no matter how valuable Bitcoins become, one can trade them in practical quantities. <br />
<br />
In fact, infinite divisibility should allow Bitcoins to function in cases of extreme wallet loss. Even if, in the far future, so many people have lost their wallets that only a single Bitcoin, or a fraction of one, remains, Bitcoin should continue to function just fine. No one can claim to be sure what is going to happen, but deflation may prove to present a smaller threat than many expect.<br />
<br />
For more information, see the [[Deflationary spiral]] page.<br />
<br />
=== What if someone bought up all the existing Bitcoins? ===<br />
Bitcoin markets are competitive -- meaning the price of a bitcoin will rise or fall depending on supply and demand at certain price levels. Only a fraction of bitcoins issued to date are found on the exchange markets for sale. So even though technically a buyer with lots of money could buy all the bitcoins offered for sale, unless those holding the rest of the bitcoins offer them for sale as well, even the wealthiest, most determined buyer can't get at them.<br />
<br />
Additionally, new currency continues to be issued daily and will continue to do so for decades though over time the rate at which they are issued declines to insignificant levels. Those who are mining aren't obligated to sell their bitcoins so not all bitcoins will make it to the markets even.<br />
<br />
This situation doesn't suggest, however, that the markets aren't vulnerable to price manipulation. It doesn't take significant amounts of money to move the market price up or down and thus Bitcoin remains a volatile asset.<br />
<br />
===What if someone creates a new block chain, or a new digital currency that renders Bitcoin obsolete?===<br />
<br />
That the block chain cannot be easily forked represents one of the central security mechanisms of Bitcoin. Given the choice between two block chains, a Bitcoin miner always chooses the longer one - that is to say, the one with the more complex hash. Thusly, it ensures that each user can only spend their bitcoins once, and that no user gets ripped off.<br />
<br />
As a consequence of the block chain structure, there may at any time be many different sub-branches, and the possibility always exists of a transaction being over-written by the longest branch, if it has been recorded in a shorter one. The older a transaction is though, the lower its chances of being over-written, and the higher of becoming permanent. Although the block chain prevents one from spending more Bitcoins than one has, it means that transactions can be accidentally nullified. <br />
<br />
A new block chain would leave the network vulnerable to [[double-spending|double-spend]] attacks. However, the creation of a viable new chain presents considerable difficulty, and the possibility does not present much of a risk.<br />
<br />
Bitcoin will always choose the longer Block Chain and determines the relative length of two branches by the complexities of their hashes. Since the hash of each new block is made from that of the block preceding it, to create a block with a more complex hash, one must be prepared to do more computation than has been done by the entire Bitcoin network from the fork point up to the newest of the blocks one is trying to supersede. Needless to say, such an undertaking would require a very large amount of processing power and since Bitcoin is continually growing and expanding, it will likely only require more with the passage of time.<br />
<br />
A much more distinct and real threat to the Bitcoin use is the development of other, superior virtual currencies, which could supplant Bitcoin and render it obsolete and valueless.<br />
<br />
A great deal of careful thought and ingenuity has gone into the development of Bitcoin, but it is the first of its breed, a prototype, and vulnerable to more highly-evolved competitors. At present, any threatening rivals have yet to rear its head; Bitcoin remains the first and foremost private virtual currency, but we can offer no guarantees that it will retain that position. It would certainly be in keeping with internet history for similar system built from the same principles to supersede and cast Bitcoin into obsolescence, after time had revealed its major shortcomings. Friendster and Myspace suffered similar fates at the hand of Facebook, Napster was ousted by Limeware, Bearshare and torrent applications, and Skype has all but crushed the last few disciples of the Microsoft Messenger army. <br />
<br />
This may sound rather foreboding, so bear in mind that introduction of new and possibly better virtual currencies will not necessarily herald Bitcoin's demise. If Bitcoin establishes itself sufficiently firmly before the inception of the next generation of private, online currencies as to gain widespread acceptance and general stability, future currencies may pose little threat even if they can claim superior design.<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 />
You can see how long all other recent transactions have taken here: [http://bitcoinstats.org/ BitcoinStats.org]. <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 />
Ten minutes was specifically chosen by [[Satoshi]] as a tradeoff between propagation time of new blocks in large networks and the amount of work wasted due to chain splits. For a more technical explanation, see Satoshi's [http://www.bitcoin.org/bitcoin.pdf original technical paper].<br />
<br />
[[File:TransactionConfirmationTimesExample.PNG]]<br />
<br />
=== Do you have to wait until my transactions are confirmed in order to buy or sell things with Bitcoin? ===<br />
<br />
YES, you do, IF the transaction is non-recourse. The Bitcoin reference software does not display transactions as confirmed until six blocks have passed (confirmations). As transactions are burred in the chain they become increasingly non-reversible but are very reversible before the first confirmation. Two to six confirmations are recommended for non-recourse situations depending on the value of the transactions involved.<br />
<br />
When people ask this question they are usually thinking about applications like supermarkets. This generally is a recourse situation: if somebody tries to double-spend on a face-to-face transaction it might work a few times, but probabalistically speaking eventually one of the double-spends will get noticed, and the penalty for shoplifting charges in most localities is calibrated to be several times worse than the proceeds of a single shoplifting event.<br />
<br />
Double-spends might be a concern for something like a snack machine in a low-traffic area with no nearby security cameras. Such a machine shouldn't honor 0-confirmation payments, and should instead use some other mechanism of clearing Bitcoin or validating transactions against reversal, see the wiki article [[Myths#Point_of_sale_with_bitcoins_isn.27t_possible_because_of_the_10_minute_wait_for_confirmation|here]] for alternatives.<br />
<br />
Applications that require immediate payment processing, like supermarkets or snack machines, need to manage the risks. Here is one way to reverse an unconfirmed payment:<br />
<br />
A [[Double-spending#Finney_attack|Finney attack]], in which an attacker mines a block containing a movement of some coins back to themselves. Once they find a block solution, they quickly go to a merchant and make a purchase, then broadcast the block, thus taking back the coins. This attack is a risk primarily for goods that are dispatched immediately, like song downloads or currency trades. Because the attacker can't choose the time of the attack, it isn't a risk for merchants such as supermarkets where you can't choose exactly when to pay (due to queues, etc). The attack can fail if somebody else finds a block containing the purchasing transaction before you release your own block, therefore, merchants can reduce but not eliminate the risk by making purchasers wait some length of time that's less than a confirm.<br />
<br />
Because pulling off this attack is not trivial, merchants who need to sell things automatically and instantly are most likely to just price the cost of reversal fraud in, or use insurance.<br />
<br />
=== I was 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 />
The latest version of the Bitcoin-Qt client tells you how far it has yet to go in downloading the blockchain. Hover over the icon in the bottom right corner of the client to learn your client's status.<br />
<br />
If it has not caught up 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://blockchain.info 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 />
If the transaction is based on a coin that was in a recent transaction then it could be considered a low priority transaction. Transfers can take longer if the transaction fee paid was not high enough. If there is no fee at all the transfer can get a very low priority and take hours or even 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 />
A fee might be imposed because your transaction looks like a denial of service attack to the Bitcoin system. For example, it might be burdensome to transmit or it might recycle Bitcoins you recently received. The wallet software attempts to avoid generating burdensome transactions, but it isn't always able to do so: The funds in your wallet might be new or composed of many tiny payments. <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 the pattern of conventional consumer or business transactions. <br />
<br />
As of Bitcoin 0.5.3 the required fee will not be higher than 0.05 BTC. For most users there is usually no required fee at all. If a fee is required it will most commonly be 0.0005 BTC.<br />
<br />
=== What happens when someone sends me a bitcoin but my computer is powered off? ===<br />
<br />
Bitcoins are not 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 />
If you are sent coins when your wallet client program is not running, and you later launch the wallet client program, the coins will eventually appear as if they were just received in the wallet. That is to say, when the client program is started it must download blocks and catch up with any transactions it did not already know about.<br />
<br />
=== How long does "synchronizing" take when the Bitcoin client is first installed? What's it doing? ===<br />
<br />
The popular Bitcoin client software from bitcoin.org implements a "full" Bitcoin node: It can carry out all the duties of the Bitcoin P2P system, it isn't simply a "client". One of the principles behind the operation of full Bitcoin nodes is that they don't assume that the other participants have followed the rules of the Bitcoin system. During synchronization, the software is processing historical Bitcoin transactions and making sure for itself that all of the rules of the system have been correctly followed.<br />
<br />
In normal operation, after synchronizing, the software should use a hardly noticeable amount of your computer's resources.<br />
<br />
When the wallet client program is first installed, its initial validation requires a lot of work from your computer's hard disk, so the amount of time to synchronize depends on your disk speed and, to a lesser extent, your CPU speed. It can take anywhere from a few hours to a day or so. On a slow computer it could take more than 40 hours of continuous synchronization, so check your computer's power-saving settings to ensure that it does not turn its hard disk off when unattended for a few hours. You can use the Bitcoin software during synchronization, but you may not see recent payments to you until the client program has caught up to the point where those transactions happened.<br />
<br />
If you feel that this process takes too long, you can download a pre-synchronized blockchain from [http://eu2.bitcoincharts.com/blockchain/ http://eu2.bitcoincharts.com/blockchain/]. Alternatively, you can try an alternative "lite" client such as Multibit or a super-light client like electrum, though these clients have somewhat weaker security, are less mature, and don't contribute to the health of the P2P network.<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. [[Testnet]] uses TCP port 18333 instead of 8333.<br />
<br />
If you want to restrict your firewall rules to a few IPs, you can find stable nodes in the [[Fallback Nodes|fallback nodes list]].<br />
<br />
=== How does the peer finding mechanism work? ===<br />
<br />
Bitcoin finds peers primarily by forwarding peer announcements within its own network and each node saves a database of peers that it's aware of, for future use. In order to bootstrap this process Bitcoin needs a list of initial peers, these can be provided manually but normally it obtains them by querying a set of DNS domain names which have automatically updated lists, if that doesn't work it falls back to a built-in list which is updated from time to time in new versions of the software. There is also an IRC based mechanism but it is disabled by default.<br />
<br />
==Mining==<br />
===What is mining?===<br />
[[Mining]] is the process of spending computation power to secure Bitcoin transactions against reversal and introducing new Bitcoins to the system.<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 (25 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 />
===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 and securing 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 [http://bitcoin.stackexchange.com/questions/5617/why-are-bitcoin-calculation-useless/5618#5618 very specific features]. These features are incompatible with leveraging the computation for other purposes.<br />
<br />
===How can we stop miners from creating zero transaction blocks?===<br />
The incentive for miners to include transactions is in the fees that come along with them. If we were to implement some minimum number of transactions per block it would be trivial for a miner to create and include transactions merely to surpass that threshold. As the network matures, the block reward drops, and miners become more dependent on transactions fees to pay their costs, the problem of zero transaction blocks should diminish over time.<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 the payload and a specific nonce, only a single call of the hashing function is needed to verify that the hash has the required properties. Since there is no known way to find these hashes other than brute force, this can be used as a "proof of work" 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/Hashcash Hashcash] and [http://en.wikipedia.org/wiki/Proof-of-work_system Proof-of-work system] and [http://en.wikipedia.org/wiki/SHA2 SHA2] and on Wikipedia.<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|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 />
==Security==<br />
<br />
===Could miners collude to give themselves money or to fundamentally change the nature of Bitcoin?===<br />
<br />
There are two questions in here. Let's look at them separately.<br />
<br />
;Could miners gang up and give themselves money?<br />
<br />
Mining itself is the process of creating new blocks in the block chain. Each block contains a list of all the transactions that have taken place across the entire Bitcoin network since the last block was created, as well as a hash of the previous block. New blocks are 'mined', or rather, generated, by Bitcoin clients correctly guessing sequences of characters in codes called 'hashes,' which are created using information from previous blocks. Bitcoin users may download specialized 'mining' software, which allows them to dedicate some amount of their processing power – however large or small – to guessing at strings within the hash of the previous block. Whoever makes the right guess first, thus creating a new block, receives a reward in Bitcoins.<br />
<br />
The block chain is one of the two structures that makes Bitcoin secure, the other being the public-key encryption system on which Bitcoin trade is based. The block chain assures that not only is every single transaction that ever takes place recorded, but that every single transaction is recorded on the computer of anyone who chooses to store the relevant information. Many, many users have complete records of every transaction in Bitcoins history readily available to them at any point, and anyone who wants in the information can obtain it with ease. These things make Bitcoin very hard to fool.<br />
<br />
The Bitcoin network takes considerable processing power to run, and since those with the most processing power can make the most guesses, those who put the most power toward to sustaining the network earn the most currency. Each correct guess yields, at present, fifty Bitcoins, and as Bitcoins are presently worth something (although the value still fluctuates) every miner who earns any number of Bitcoins makes money. Some miners pull in Bitcoins on their own; and some also join or form pools wherein all who contribute earn a share of the profits. <br />
<br />
Therefore, first answer is a vehement “yes” – no only can miners collude to get more money, Bitcoin is designed to encourage them to do so. Bitcoin pools are communal affairs, and there is nothing dishonest or underhanded about them.<br />
<br />
Of course, the real question is:<br />
<br />
;Can they do so in ways not sanction by Bitcoin developers? Is there any way to rip off the network and make loads of money dishonestly?<br />
<br />
Bitcoin isn't infallible. It can be cheated, but doing so is extremely difficult. Bitcoin was designed to evade some of the central problems with modern currencies – namely, that their trustworthiness hinges upon that of people who might not have users' best interests in mind. Every currency in the world (other than Bitcoin) is controlled by large institutions who keep track of what's done with it, and who can manipulate its value. And every other currency has value because people trust the institutions that control them.<br />
<br />
Bitcoin doesn't ask that its users trust any institution. Its security is based on the cryptography that is an integral part of its structure, and that is readily available for any and all to see. Instead of one entity keeping track of transactions, the entire network does, so Bitcoins are astoundingly difficult to steal, or double-spend. Bitcoins are created in a regular and predictable fashion, and by many different users, so no one can decide to make a whole lot more and lessen their value. In short, Bitcoin is designed to be inflation-proof, double-spend-proof and completely distributed.<br />
<br />
Nonetheless, there are a few ways that one can acquire Bitcoins dishonestly. Firstly, one can steal private keys. Key theft isn't something that Bitcoin security has been designed to prevent: it's up to users to keep theirs safe. But the cryptography is designed so that it is completely impossible to deduce someone's private key from their public one. As long as you keep your private key to yourself, you don't have much to worry about. Furthermore, one could theoretically create a new block chain, but due to the way in which the block chain is constructed, this would be extremely difficult and require massive amounts of processing power. A full explanation of the difficulties involved can be found in the [[block chain]] article.<br />
<br />
Bitcoin can be ripped off – but doing so would be extremely hard and require considerable expertise and a staggering amount of processing power. And it's only going to get harder with time. Bitcoin isn't impenetrable, but it's close enough to put any real worries in the peripherals.<br />
<br />
;Could miners fundamentally change the nature of Bitcoin?<br />
<br />
Once again, almost certainly not.<br />
<br />
Bitcoin is a distributed network, so any changes implemented to the system must be accepted by all users. Someone trying to change the way Bitcoins are generated would have to convince every user to download and use their software – so the only changes that would go through are those that would be equally benefit all users. <br />
<br />
And thus, it is more or less impossible for anyone to change the function of Bitcoin to their advantage. If users don't like the changes, they won't adopt them, whereas if users do like them, then these will help everyone equally. Of course, one can conceive of a situation where someone manages to get a change pushed through that provides them with an advantage that no one notices, but given that Bitcoin is structurally relatively simple, it is unlikely that any major changes will go through without someone noticing first.<br />
<br />
The fact that such changes are so difficult to make testifies to the fully distributed nature of Bitcoin. Any centrally controlled currency can be modified by its central agency without the consent of its adherents. Bitcoin has no central authority, so it changes only at the behest of the whole community. Bitcoins development represents a kind of collective evolution; the first of its kind among currencies.<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 />
[[ru:FAQ]]<br />
<br />
[[Category:Technical]]<br />
[[Category:Vocabulary]]</div>Amincdhttps://en.bitcoin.it/w/index.php?title=Friendly_addresses_with_enhanced_privacy&diff=25259Friendly addresses with enhanced privacy2012-04-12T02:17:37Z<p>Amincd: /* UnSpammable Publication of Friendly Address Owners' Public Keys */</p>
<hr />
<div>The 'friendly addresses with enhanced privacy' protocol, [https://bitcointalk.org/index.php?topic=74572.0 proposed] by BubbleBoy, would provide increased privacy and improved usability in bitcoin usage. The proposal in its original form is reproduced here:<br />
<br />
==Proposal==<br />
<br />
It's my opinion that exposing a SHA256 hash to the general public is bad usability. People would much rather publish a friendly address in a format that can easily be dictated over the phone, written down or memorized, similar to the way PayPal/Skrill/Neteller work, where an email address is the identity of the account holder. They would also like to include private payment details with each transaction, such as invoice numbers, and have the option of easily providing a refund when they desire.<br />
<br />
Additionally, publishing a single base58 hash ''reduces privacy'' because it can help trace related payments to that address. A political candidate might not want to disclose the total amount of donations received. As a donor, I wouldn't want my friend and business partners to find out that some of the money they sent me ended up in a well known collection box. Since ECDSA keys are cheap, maximum privacy is achieved when each real world transaction has it's own unique address, and they are not aggregated in a master key, but rather spent individually by the recipient.<br />
<br />
Combining the two requirements, I am proposing a distributed online protocol that resolves friendly names to base58 hashes, ensuring at the same time that each transaction has it's own unique address. The protocol works using a trusted 3rd party that acts as an always-on relay point on behalf of the user, similar to an email server. The payload (money / private keys) is not under the server's control, only the public address list and their mapping to a friendly address. Privacy focused individuals who don't want to disclose even the transaction list to a 3rd party can host their own relay server.<br />
<br />
A conceptual workflow would go something like this:<br />
* Alice creates a large number of private keys and stores them offline, keeping only the public corresponding public addresses; for space concerns the private keys could be generated based on a single seed that is easy to store<br />
* Alice creates an account on the relay server, establishes an authentication token, and assigns herself a friendly address: alice@example.com <br />
* Using her authentication token, Alice's client periodically contacts the relay server and queries for recent activity related to her account ("activity" will be defined bellow); if the base58 address pool is depleted, for example on first connect, the client uploads fresh keys generated in step 1<br />
* Alice publishes her friendly address to friends, family, business partners, Bob and Mallory<br />
* When Bob desires to make a payment to Alice, he enters Alice's friendly address in his client, the amount to send, some description and any other application-specific data<br />
* Bob's client scans it's wallet and discovers it can match Bob's entered amount exactly by spending three private keys it owns<br />
* Bob's client parses the address into a server and user part, contacts the relay server via DNS/HTTP and POSTs a request for a transaction. For example the post address and data could go something like this:<br />
:POST to: https://example.com/relay_server<br />
:URL-encoded data:<br />
:user=alice&currency=BTC&amount=500&want_addr=3&description=Paycheck%20December&payer=bob@example.or:g&meta1=value1&meta2=value2&...<br />
* The relay server extracts three of Alice's base58 hashes from the pool of [i]available hashes[/i], records them in the database of [i]used hashes[/i] along with the information posted by Bob, and returns the addresses to Bob's client<br />
* Bob's client makes transactions as usual to the addresses it obtained, and publishes them in the blockchain<br />
* On the next refresh, Alice's client will contact the server and find what addresses where used, and the associated payer meta information; if the transactions exists in the blockchain, then Alice will be able to see a user friendly entry in her incoming log, that maps all 3 sends to a single entry and shows the associated payer addr and meta information, just like a regular e-wallet<br />
<br />
<br />
For maximum compatibility and easy deployment, the server works on top of DNS and HTTP, but it could be also deployed over Namecoin/Tor. It's also coin agnostic and could be implemented for any other currency besides Bitcoin. If Bob does not want to disclose his IP address to Alice's relay server, he can resolve her friendly name via Tor. It's also optional for Bob to disclose or not his own friendly address under the "payer" POST field.<br />
<br />
The system has the advantage that Mallory cannot find anything by queering the relay server. She will obtain a unique and random string that is never used in the blockchain and reveals no information about Alice. The only way to find out more is to send money to Alice and trance them further. But if Alice employs the same protocol when spending the money received from Mallory, then Mallory cannot find '''anything''' about Alice's other partners. <br />
<br />
The protocol offers the convenience of systems such as PayPal without spamming the blockchain with metadata (payment details); metadata is kept private, known only by the Bob, Alice and the server, and it can also be encrypted to exclude the server. It allows easy refund if the payer chose to disclose a return address; without the payer's friendly address, refunds to a base58 addresses are a bad ideea since there is no guarantee the sender has kept the corresponding private key.<br />
<br />
I'm not necessarily keen to have friendly addresses formatted like an email especially since this address would not have email capabilities; The friendly address syntax is yet to be defined and there are a myriad alternatives: alice$example.com, alice^example.com, btc:example.com~alice etc. I've also skimmed over the low level details for server communication since it's too early to lay down the implementation details. Also, DoS by emptying the pool of available hashes should be prevented.<br />
<br />
<br />
'''Later edit, April 03, 2012:'''<br />
<br />
The naive scheme presented above is very vulnerable to a man-in-the middle attack. Alice must trust the relay server, the DNS system, and the SSL provider of example.com; they could conspire to hand out fake keys that are not owned by Alice, seize all of Alice's funds, and log all payment details. <br />
<br />
But the sender and the recipient already have an unforgeable channel at their disposal: the blockchain. Why not use this channel to establish a trusted public key, thus widely reducing the middle man's (relay server) maneuvering capabilities ?<br />
<br />
It could go something like this:<br />
* Alice wants the friendly name alice@example.com, and the owners of example.com allow her to register it<br />
* Alice hashes the friendly name with RIPEMD160, and constructs a globally unique, unspendable bitcoin address: base58(ripemd160("alice@example.com") +checksum),<br />
* The address is unspendable since it's not a hash of a public key; only Alice and friends know this, and it cannot be detected<br />
* Alice creates a ECDSA keypair, and uses it to sign a transfer of a few bitcents to the unspendable address<br />
* Alice has just published ownership of the "alice@example.com" friendly name, with none of the Bitcoin participants seeing anything other than a regular Bitcoin transaction <br />
* Bob wants to send Alice some coins; he repeats the ripmend160 hashing and gets to the unspendable address<br />
* Bob scans his blockchain for spends to this address; it's expected the blockchain is properly indexed for such scans to be cheap<br />
* He finds the single unspent transaction made by Alice, thus obtains her public key<br />
* He contacts the relay server @example.com, and uses the Alice's ECDSA public key to cut the middle man out of the loop:<br />
* The transaction metadata is passed to the relay server as a binary blob, encrypted for Alices's private key using ECIES<br />
* Each address previously uploaded by Alice to the relay server is signed, so Bob can have full confidence Alice gets the money<br />
<br />
Using this scheme, Alice maintains good privacy (she publishes a hashed version of her address), and does not have to trust the relay server with her money or personal data. <br />
<br />
What happens if Mallory finds Alice's friendly address, and broadcasts her own transaction to base58(ripemd160("alice@example.com") +checksum), with her own public key ? Bob should accept only the first valid transaction, and ignore later ones. This has the disadvantage that if Alice looses her initial keypair, "alice@example.com" is unusable for eternity. A more complex scheme could be devised where updates, revokes and reuse can be enabled.<br />
<br />
What about address colisions ? RIPEMD160 80 bits of collision resistance should offer sufficient protection against accidental collisions; for deliberate collisions, we are exactly in the previous situations and the protocol should prevent it.<br />
<br />
There seem to be at least two similar but-incompatible schemes for doing what I proposed above as the "naive approach". Here I was thinking I am being original :):<br />
* https://en.bitcoin.it/wiki/BIP_0015<br />
* http://ecdsa.org/bitcoin_URIs.html<br />
<br />
Judging by [http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg00419.html|discussion in the mailing list], BIP15 was deferred because it lacked a clear way to authenticate the relay (alias) server. HTTPS is not enough.<br />
The electrum proposal tries to do some authentication, using an undefined "trusted authority". Not very useful.<br />
If we can define a good way to publish Alice's pubkey into the blockchain and use it further to authenticate and encrypt the exchange, we are making progress towards a working protocol. Coin destruction and spamming should be kept to a minimum or zero.<br />
<br />
==UnSpammable Publication of Friendly Address Owners' Public Keys==<br />
<br />
Using the Namecoin block-chain, it is possible to enable the friendly address owner to publish their pubkey for secure communication with their friendly address, without also enabling an attacker to make large numbers of desirable user accounts of any given domain unavailable by publishing ownership over them in the bitcoin block-chain without the domain owner's permission. The scheme, proposed by Amincd [https://bitcointalk.org/index.php?topic=74572.msg847022#msg847022 here], would work as follows:<br />
<br />
*A relay server registers example.bit in the namecoin block-chain.<br />
*The relay server creates a base58(ripemd160("example.bit") +checksum)) hash, and sends a namecoin-bitcent/satoshi/etc to it from the namecoin address that example.bit is registered with at the time, thus publishing the pubkey of example.bit, which will be used to verify its signatures<br />
* When Alice is registering alice@example.bit, the relay server creates a digital signature for "alice@example.bit" using the privkey of the example.bit pubkey published in the namecoin block-chain, and sends it to Alice through a secure channel<br />
* Alice creates a bitcoin transaction, sending one bitcent/satoshi/etc to base58(ripemd160(example.bit-signature("alice@example.bit") +checksum)), thus publishing her public key.<br />
* When Bob wants to make a payment to alice@example.bit, he scans the namecoin block-chain for the earliest spend to base58(ripemd160("example.bit") +checksum))<br />
* He checks if the spend came from the namecoin address that example.bit was registered at at the time of the spend, and if it didn't, he looks for the next earliest spend, and does this until he finds a spend to base58(ripemd160("example.bit") +checksum)) that came from example.bit's namecoin address<br />
* Once Bob finds the spend, he considers the pubkey used for the spend as example.bit's official pubkey for signature verification<br />
* Bob asks example.bit for a digital signature of alice@example.bit, and uses example.bit's published pubkey to verify the signature was made by example.bit's official privkey<br />
* Bob scans the bitcoin block-chain for the earliest spend to base58(ripemd160(example.bit-signature("alice@example.bit") +checksum), and obtains Alice's pubkey<br />
* There is no way the owners of example.bit could have cheated and given Bob a different signature for alice@example.bit than they gave to Alice when she published her pubkey, because every namecoin domain can only ever have one official pubkey, that can never be altered<br />
<br />
[[Category:Technical]]</div>Amincdhttps://en.bitcoin.it/w/index.php?title=Friendly_addresses_with_enhanced_privacy&diff=25253Friendly addresses with enhanced privacy2012-04-11T21:38:23Z<p>Amincd: /* UnSpammable Publication of Friendly Address Owners' Public Keys */</p>
<hr />
<div>The 'friendly addresses with enhanced privacy' protocol, [https://bitcointalk.org/index.php?topic=74572.0 proposed] by BubbleBoy, would provide increased privacy and improved usability in bitcoin usage. The proposal in its original form is reproduced here:<br />
<br />
==Proposal==<br />
<br />
It's my opinion that exposing a SHA256 hash to the general public is bad usability. People would much rather publish a friendly address in a format that can easily be dictated over the phone, written down or memorized, similar to the way PayPal/Skrill/Neteller work, where an email address is the identity of the account holder. They would also like to include private payment details with each transaction, such as invoice numbers, and have the option of easily providing a refund when they desire.<br />
<br />
Additionally, publishing a single base58 hash ''reduces privacy'' because it can help trace related payments to that address. A political candidate might not want to disclose the total amount of donations received. As a donor, I wouldn't want my friend and business partners to find out that some of the money they sent me ended up in a well known collection box. Since ECDSA keys are cheap, maximum privacy is achieved when each real world transaction has it's own unique address, and they are not aggregated in a master key, but rather spent individually by the recipient.<br />
<br />
Combining the two requirements, I am proposing a distributed online protocol that resolves friendly names to base58 hashes, ensuring at the same time that each transaction has it's own unique address. The protocol works using a trusted 3rd party that acts as an always-on relay point on behalf of the user, similar to an email server. The payload (money / private keys) is not under the server's control, only the public address list and their mapping to a friendly address. Privacy focused individuals who don't want to disclose even the transaction list to a 3rd party can host their own relay server.<br />
<br />
A conceptual workflow would go something like this:<br />
* Alice creates a large number of private keys and stores them offline, keeping only the public corresponding public addresses; for space concerns the private keys could be generated based on a single seed that is easy to store<br />
* Alice creates an account on the relay server, establishes an authentication token, and assigns herself a friendly address: alice@example.com <br />
* Using her authentication token, Alice's client periodically contacts the relay server and queries for recent activity related to her account ("activity" will be defined bellow); if the base58 address pool is depleted, for example on first connect, the client uploads fresh keys generated in step 1<br />
* Alice publishes her friendly address to friends, family, business partners, Bob and Mallory<br />
* When Bob desires to make a payment to Alice, he enters Alice's friendly address in his client, the amount to send, some description and any other application-specific data<br />
* Bob's client scans it's wallet and discovers it can match Bob's entered amount exactly by spending three private keys it owns<br />
* Bob's client parses the address into a server and user part, contacts the relay server via DNS/HTTP and POSTs a request for a transaction. For example the post address and data could go something like this:<br />
:POST to: https://example.com/relay_server<br />
:URL-encoded data:<br />
:user=alice&currency=BTC&amount=500&want_addr=3&description=Paycheck%20December&payer=bob@example.or:g&meta1=value1&meta2=value2&...<br />
* The relay server extracts three of Alice's base58 hashes from the pool of [i]available hashes[/i], records them in the database of [i]used hashes[/i] along with the information posted by Bob, and returns the addresses to Bob's client<br />
* Bob's client makes transactions as usual to the addresses it obtained, and publishes them in the blockchain<br />
* On the next refresh, Alice's client will contact the server and find what addresses where used, and the associated payer meta information; if the transactions exists in the blockchain, then Alice will be able to see a user friendly entry in her incoming log, that maps all 3 sends to a single entry and shows the associated payer addr and meta information, just like a regular e-wallet<br />
<br />
<br />
For maximum compatibility and easy deployment, the server works on top of DNS and HTTP, but it could be also deployed over Namecoin/Tor. It's also coin agnostic and could be implemented for any other currency besides Bitcoin. If Bob does not want to disclose his IP address to Alice's relay server, he can resolve her friendly name via Tor. It's also optional for Bob to disclose or not his own friendly address under the "payer" POST field.<br />
<br />
The system has the advantage that Mallory cannot find anything by queering the relay server. She will obtain a unique and random string that is never used in the blockchain and reveals no information about Alice. The only way to find out more is to send money to Alice and trance them further. But if Alice employs the same protocol when spending the money received from Mallory, then Mallory cannot find '''anything''' about Alice's other partners. <br />
<br />
The protocol offers the convenience of systems such as PayPal without spamming the blockchain with metadata (payment details); metadata is kept private, known only by the Bob, Alice and the server, and it can also be encrypted to exclude the server. It allows easy refund if the payer chose to disclose a return address; without the payer's friendly address, refunds to a base58 addresses are a bad ideea since there is no guarantee the sender has kept the corresponding private key.<br />
<br />
I'm not necessarily keen to have friendly addresses formatted like an email especially since this address would not have email capabilities; The friendly address syntax is yet to be defined and there are a myriad alternatives: alice$example.com, alice^example.com, btc:example.com~alice etc. I've also skimmed over the low level details for server communication since it's too early to lay down the implementation details. Also, DoS by emptying the pool of available hashes should be prevented.<br />
<br />
<br />
'''Later edit, April 03, 2012:'''<br />
<br />
The naive scheme presented above is very vulnerable to a man-in-the middle attack. Alice must trust the relay server, the DNS system, and the SSL provider of example.com; they could conspire to hand out fake keys that are not owned by Alice, seize all of Alice's funds, and log all payment details. <br />
<br />
But the sender and the recipient already have an unforgeable channel at their disposal: the blockchain. Why not use this channel to establish a trusted public key, thus widely reducing the middle man's (relay server) maneuvering capabilities ?<br />
<br />
It could go something like this:<br />
* Alice wants the friendly name alice@example.com, and the owners of example.com allow her to register it<br />
* Alice hashes the friendly name with RIPEMD160, and constructs a globally unique, unspendable bitcoin address: base58(ripemd160("alice@example.com") +checksum),<br />
* The address is unspendable since it's not a hash of a public key; only Alice and friends know this, and it cannot be detected<br />
* Alice creates a ECDSA keypair, and uses it to sign a transfer of a few bitcents to the unspendable address<br />
* Alice has just published ownership of the "alice@example.com" friendly name, with none of the Bitcoin participants seeing anything other than a regular Bitcoin transaction <br />
* Bob wants to send Alice some coins; he repeats the ripmend160 hashing and gets to the unspendable address<br />
* Bob scans his blockchain for spends to this address; it's expected the blockchain is properly indexed for such scans to be cheap<br />
* He finds the single unspent transaction made by Alice, thus obtains her public key<br />
* He contacts the relay server @example.com, and uses the Alice's ECDSA public key to cut the middle man out of the loop:<br />
* The transaction metadata is passed to the relay server as a binary blob, encrypted for Alices's private key using ECIES<br />
* Each address previously uploaded by Alice to the relay server is signed, so Bob can have full confidence Alice gets the money<br />
<br />
Using this scheme, Alice maintains good privacy (she publishes a hashed version of her address), and does not have to trust the relay server with her money or personal data. <br />
<br />
What happens if Mallory finds Alice's friendly address, and broadcasts her own transaction to base58(ripemd160("alice@example.com") +checksum), with her own public key ? Bob should accept only the first valid transaction, and ignore later ones. This has the disadvantage that if Alice looses her initial keypair, "alice@example.com" is unusable for eternity. A more complex scheme could be devised where updates, revokes and reuse can be enabled.<br />
<br />
What about address colisions ? RIPEMD160 80 bits of collision resistance should offer sufficient protection against accidental collisions; for deliberate collisions, we are exactly in the previous situations and the protocol should prevent it.<br />
<br />
There seem to be at least two similar but-incompatible schemes for doing what I proposed above as the "naive approach". Here I was thinking I am being original :):<br />
* https://en.bitcoin.it/wiki/BIP_0015<br />
* http://ecdsa.org/bitcoin_URIs.html<br />
<br />
Judging by [http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg00419.html|discussion in the mailing list], BIP15 was deferred because it lacked a clear way to authenticate the relay (alias) server. HTTPS is not enough.<br />
The electrum proposal tries to do some authentication, using an undefined "trusted authority". Not very useful.<br />
If we can define a good way to publish Alice's pubkey into the blockchain and use it further to authenticate and encrypt the exchange, we are making progress towards a working protocol. Coin destruction and spamming should be kept to a minimum or zero.<br />
<br />
==UnSpammable Publication of Friendly Address Owners' Public Keys==<br />
<br />
Using the Namecoin block-chain, it is possible for the friendly address owner to publish their pubkey for secure communication with their friendly address, without also enabling an attacker to make large numbers of desirable user accounts of any given domain unavailable by publishing ownership over them in the bitcoin block-chain without the domain owner's permission. The scheme, proposed by Amincd [https://bitcointalk.org/index.php?topic=74572.msg847022#msg847022 here], would work as follows:<br />
<br />
*A relay server registers example.bit in the namecoin block-chain.<br />
*The relay server creates a base58(ripemd160("example.bit") +checksum)) hash, and sends a namecoin-bitcent/satoshi/etc to it from the namecoin address that example.bit is registered with at the time, thus publishing the pubkey of example.bit, which will be used to verify its signatures<br />
* When Alice is registering alice@example.bit, the relay server creates a digital signature for "alice@example.bit" using the privkey of the example.bit pubkey published in the namecoin block-chain, and sends it to Alice through a secure channel<br />
* Alice creates a bitcoin transaction, sending one bitcent/satoshi/etc to base58(ripemd160(example.bit-signature("alice@example.bit") +checksum)), thus publishing her public key.<br />
* When Bob wants to make a payment to alice@example.bit, he scans the namecoin block-chain for the earliest spend to base58(ripemd160("example.bit") +checksum))<br />
* He checks if the spend came from the namecoin address that example.bit was registered at at the time of the spend, and if it didn't, he looks for the next earliest spend, and does this until he finds a spend to base58(ripemd160("example.bit") +checksum)) that came from example.bit's namecoin address<br />
* Once Bob finds the spend, he considers the pubkey used for the spend as example.bit's official pubkey for signature verification<br />
* Bob asks example.bit for a digital signature of alice@example.bit, and uses example.bit's published pubkey to verify the signature was made by example.bit's official privkey<br />
* Bob scans the bitcoin block-chain for the earliest spend to base58(ripemd160(example.bit-signature("alice@example.bit") +checksum), and obtains Alice's pubkey<br />
* There is no way the owners of example.bit could have cheated and given Bob a different signature for alice@example.bit than they gave to Alice when she published her pubkey, because every namecoin domain can only ever have one official pubkey, that can never be altered<br />
<br />
[[Category:Technical]]</div>Amincdhttps://en.bitcoin.it/w/index.php?title=Friendly_addresses_with_enhanced_privacy&diff=25252Friendly addresses with enhanced privacy2012-04-11T21:35:11Z<p>Amincd: </p>
<hr />
<div>The 'friendly addresses with enhanced privacy' protocol, [https://bitcointalk.org/index.php?topic=74572.0 proposed] by BubbleBoy, would provide increased privacy and improved usability in bitcoin usage. The proposal in its original form is reproduced here:<br />
<br />
==Proposal==<br />
<br />
It's my opinion that exposing a SHA256 hash to the general public is bad usability. People would much rather publish a friendly address in a format that can easily be dictated over the phone, written down or memorized, similar to the way PayPal/Skrill/Neteller work, where an email address is the identity of the account holder. They would also like to include private payment details with each transaction, such as invoice numbers, and have the option of easily providing a refund when they desire.<br />
<br />
Additionally, publishing a single base58 hash ''reduces privacy'' because it can help trace related payments to that address. A political candidate might not want to disclose the total amount of donations received. As a donor, I wouldn't want my friend and business partners to find out that some of the money they sent me ended up in a well known collection box. Since ECDSA keys are cheap, maximum privacy is achieved when each real world transaction has it's own unique address, and they are not aggregated in a master key, but rather spent individually by the recipient.<br />
<br />
Combining the two requirements, I am proposing a distributed online protocol that resolves friendly names to base58 hashes, ensuring at the same time that each transaction has it's own unique address. The protocol works using a trusted 3rd party that acts as an always-on relay point on behalf of the user, similar to an email server. The payload (money / private keys) is not under the server's control, only the public address list and their mapping to a friendly address. Privacy focused individuals who don't want to disclose even the transaction list to a 3rd party can host their own relay server.<br />
<br />
A conceptual workflow would go something like this:<br />
* Alice creates a large number of private keys and stores them offline, keeping only the public corresponding public addresses; for space concerns the private keys could be generated based on a single seed that is easy to store<br />
* Alice creates an account on the relay server, establishes an authentication token, and assigns herself a friendly address: alice@example.com <br />
* Using her authentication token, Alice's client periodically contacts the relay server and queries for recent activity related to her account ("activity" will be defined bellow); if the base58 address pool is depleted, for example on first connect, the client uploads fresh keys generated in step 1<br />
* Alice publishes her friendly address to friends, family, business partners, Bob and Mallory<br />
* When Bob desires to make a payment to Alice, he enters Alice's friendly address in his client, the amount to send, some description and any other application-specific data<br />
* Bob's client scans it's wallet and discovers it can match Bob's entered amount exactly by spending three private keys it owns<br />
* Bob's client parses the address into a server and user part, contacts the relay server via DNS/HTTP and POSTs a request for a transaction. For example the post address and data could go something like this:<br />
:POST to: https://example.com/relay_server<br />
:URL-encoded data:<br />
:user=alice&currency=BTC&amount=500&want_addr=3&description=Paycheck%20December&payer=bob@example.or:g&meta1=value1&meta2=value2&...<br />
* The relay server extracts three of Alice's base58 hashes from the pool of [i]available hashes[/i], records them in the database of [i]used hashes[/i] along with the information posted by Bob, and returns the addresses to Bob's client<br />
* Bob's client makes transactions as usual to the addresses it obtained, and publishes them in the blockchain<br />
* On the next refresh, Alice's client will contact the server and find what addresses where used, and the associated payer meta information; if the transactions exists in the blockchain, then Alice will be able to see a user friendly entry in her incoming log, that maps all 3 sends to a single entry and shows the associated payer addr and meta information, just like a regular e-wallet<br />
<br />
<br />
For maximum compatibility and easy deployment, the server works on top of DNS and HTTP, but it could be also deployed over Namecoin/Tor. It's also coin agnostic and could be implemented for any other currency besides Bitcoin. If Bob does not want to disclose his IP address to Alice's relay server, he can resolve her friendly name via Tor. It's also optional for Bob to disclose or not his own friendly address under the "payer" POST field.<br />
<br />
The system has the advantage that Mallory cannot find anything by queering the relay server. She will obtain a unique and random string that is never used in the blockchain and reveals no information about Alice. The only way to find out more is to send money to Alice and trance them further. But if Alice employs the same protocol when spending the money received from Mallory, then Mallory cannot find '''anything''' about Alice's other partners. <br />
<br />
The protocol offers the convenience of systems such as PayPal without spamming the blockchain with metadata (payment details); metadata is kept private, known only by the Bob, Alice and the server, and it can also be encrypted to exclude the server. It allows easy refund if the payer chose to disclose a return address; without the payer's friendly address, refunds to a base58 addresses are a bad ideea since there is no guarantee the sender has kept the corresponding private key.<br />
<br />
I'm not necessarily keen to have friendly addresses formatted like an email especially since this address would not have email capabilities; The friendly address syntax is yet to be defined and there are a myriad alternatives: alice$example.com, alice^example.com, btc:example.com~alice etc. I've also skimmed over the low level details for server communication since it's too early to lay down the implementation details. Also, DoS by emptying the pool of available hashes should be prevented.<br />
<br />
<br />
'''Later edit, April 03, 2012:'''<br />
<br />
The naive scheme presented above is very vulnerable to a man-in-the middle attack. Alice must trust the relay server, the DNS system, and the SSL provider of example.com; they could conspire to hand out fake keys that are not owned by Alice, seize all of Alice's funds, and log all payment details. <br />
<br />
But the sender and the recipient already have an unforgeable channel at their disposal: the blockchain. Why not use this channel to establish a trusted public key, thus widely reducing the middle man's (relay server) maneuvering capabilities ?<br />
<br />
It could go something like this:<br />
* Alice wants the friendly name alice@example.com, and the owners of example.com allow her to register it<br />
* Alice hashes the friendly name with RIPEMD160, and constructs a globally unique, unspendable bitcoin address: base58(ripemd160("alice@example.com") +checksum),<br />
* The address is unspendable since it's not a hash of a public key; only Alice and friends know this, and it cannot be detected<br />
* Alice creates a ECDSA keypair, and uses it to sign a transfer of a few bitcents to the unspendable address<br />
* Alice has just published ownership of the "alice@example.com" friendly name, with none of the Bitcoin participants seeing anything other than a regular Bitcoin transaction <br />
* Bob wants to send Alice some coins; he repeats the ripmend160 hashing and gets to the unspendable address<br />
* Bob scans his blockchain for spends to this address; it's expected the blockchain is properly indexed for such scans to be cheap<br />
* He finds the single unspent transaction made by Alice, thus obtains her public key<br />
* He contacts the relay server @example.com, and uses the Alice's ECDSA public key to cut the middle man out of the loop:<br />
* The transaction metadata is passed to the relay server as a binary blob, encrypted for Alices's private key using ECIES<br />
* Each address previously uploaded by Alice to the relay server is signed, so Bob can have full confidence Alice gets the money<br />
<br />
Using this scheme, Alice maintains good privacy (she publishes a hashed version of her address), and does not have to trust the relay server with her money or personal data. <br />
<br />
What happens if Mallory finds Alice's friendly address, and broadcasts her own transaction to base58(ripemd160("alice@example.com") +checksum), with her own public key ? Bob should accept only the first valid transaction, and ignore later ones. This has the disadvantage that if Alice looses her initial keypair, "alice@example.com" is unusable for eternity. A more complex scheme could be devised where updates, revokes and reuse can be enabled.<br />
<br />
What about address colisions ? RIPEMD160 80 bits of collision resistance should offer sufficient protection against accidental collisions; for deliberate collisions, we are exactly in the previous situations and the protocol should prevent it.<br />
<br />
There seem to be at least two similar but-incompatible schemes for doing what I proposed above as the "naive approach". Here I was thinking I am being original :):<br />
* https://en.bitcoin.it/wiki/BIP_0015<br />
* http://ecdsa.org/bitcoin_URIs.html<br />
<br />
Judging by [http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg00419.html|discussion in the mailing list], BIP15 was deferred because it lacked a clear way to authenticate the relay (alias) server. HTTPS is not enough.<br />
The electrum proposal tries to do some authentication, using an undefined "trusted authority". Not very useful.<br />
If we can define a good way to publish Alice's pubkey into the blockchain and use it further to authenticate and encrypt the exchange, we are making progress towards a working protocol. Coin destruction and spamming should be kept to a minimum or zero.<br />
<br />
==UnSpammable Publication of Friendly Address Owners' Public Keys==<br />
<br />
Using the Namecoin block-chain, it is possible for the friendly address owner to publish their pubkey for secure communication with their friendly address, without also enabling an attacker to make large numbers of desirable user accounts of any given domain unavailable by publishing ownership over them in the bitcoin block-chain without the domain owner's permission. The scheme, proposed by Amincd [https://bitcointalk.org/index.php?topic=74572.msg847022#msg847022 here], would work as follows:<br />
<br />
*A relay server registers example.bit in the namecoin block-chain.<br />
*The relay server creates a base58(ripemd160("example.bit") +checksum)) hash, and sends a namecoin-bitcent/satoshi/etc to it from the namecoin address that example.bit is registered with at the time, thus publishing the pubkey of example.bit, which will be used to verify its signatures<br />
* When Alice is registering alice@example.bit, the relay server creates a digital signature for "alice@example.bit" using the privkey of the example.bit pubkey published in the namecoin block-chain, and sends it to Alice through a secure channel<br />
* Alice creates a bitcoin transaction, sending one bitcent/satoshi/etc to base58(ripemd160(example.bit-signature("alice@example.bit") +checksum)), thus publishing her public key.<br />
* When Bob wants to make a payment to alice@example.bit, he scans the namecoin block-chain for the earliest spend to base58(ripemd160("example.bit") +checksum))<br />
* He checks if the spend came from the namecoin address that example.bit was registered at at the time of the spend, and if it didn't, he looks for the next earliest spend, and does this until he finds a spend to base58(ripemd160("example.bit") +checksum)) that came from example.bit's namecoin address<br />
* Once Bob finds the spend, he considers the pubkey used for the spend as example.bit's official pubkey for signature verification<br />
* Bob asks example.bit for a digital signature of alice@example.bit, and uses example.bit's published pubkey to verify the signature was made by example.bit's official privkey<br />
* Bob scans the bitcoin block-chain for the earliest spend to base58(ripemd160(example.bit-signature("alice@example.bit") +checksum), and obtain's Alice's pubkey<br />
* There is no way the owners of example.bit could have cheated and given Bob a different signature for alice@example.bit than they gave to Alice when she published her pubkey, because every namecoin domain can only ever have one official pubkey, that can never be altered<br />
<br />
[[Category:Technical]]</div>Amincdhttps://en.bitcoin.it/w/index.php?title=Friendly_addresses_with_enhanced_privacy&diff=25251Friendly addresses with enhanced privacy2012-04-11T21:27:51Z<p>Amincd: /* UnSpammable Publication of Friendly Address Owners' Public Keys */</p>
<hr />
<div>The 'friendly addresses with enhanced privacy' protocol, [https://bitcointalk.org/index.php?topic=74572.0 proposed] by BubbleBoy, would provide increased privacy and improved usability in bitcoin usage. The proposal in its original form is reproduced here:<br />
<br />
==Proposal==<br />
<br />
It's my opinion that exposing a SHA256 hash to the general public is bad usability. People would much rather publish a friendly address in a format that can easily be dictated over the phone, written down or memorized, similar to the way PayPal/Skrill/Neteller work, where an email address is the identity of the account holder. They would also like to include private payment details with each transaction, such as invoice numbers, and have the option of easily providing a refund when they desire.<br />
<br />
Additionally, publishing a single base58 hash ''reduces privacy'' because it can help trace related payments to that address. A political candidate might not want to disclose the total amount of donations received. As a donor, I wouldn't want my friend and business partners to find out that some of the money they sent me ended up in a well known collection box. Since ECDSA keys are cheap, maximum privacy is achieved when each real world transaction has it's own unique address, and they are not aggregated in a master key, but rather spent individually by the recipient.<br />
<br />
Combining the two requirements, I am proposing a distributed online protocol that resolves friendly names to base58 hashes, ensuring at the same time that each transaction has it's own unique address. The protocol works using a trusted 3rd party that acts as an always-on relay point on behalf of the user, similar to an email server. The payload (money / private keys) is not under the server's control, only the public address list and their mapping to a friendly address. Privacy focused individuals who don't want to disclose even the transaction list to a 3rd party can host their own relay server.<br />
<br />
A conceptual workflow would go something like this:<br />
* Alice creates a large number of private keys and stores them offline, keeping only the public corresponding public addresses; for space concerns the private keys could be generated based on a single seed that is easy to store<br />
* Alice creates an account on the relay server, establishes an authentication token, and assigns herself a friendly address: alice@example.com <br />
* Using her authentication token, Alice's client periodically contacts the relay server and queries for recent activity related to her account ("activity" will be defined bellow); if the base58 address pool is depleted, for example on first connect, the client uploads fresh keys generated in step 1<br />
* Alice publishes her friendly address to friends, family, business partners, Bob and Mallory<br />
* When Bob desires to make a payment to Alice, he enters Alice's friendly address in his client, the amount to send, some description and any other application-specific data<br />
* Bob's client scans it's wallet and discovers it can match Bob's entered amount exactly by spending three private keys it owns<br />
* Bob's client parses the address into a server and user part, contacts the relay server via DNS/HTTP and POSTs a request for a transaction. For example the post address and data could go something like this:<br />
:POST to: https://example.com/relay_server<br />
:URL-encoded data:<br />
:user=alice&currency=BTC&amount=500&want_addr=3&description=Paycheck%20December&payer=bob@example.or:g&meta1=value1&meta2=value2&...<br />
* The relay server extracts three of Alice's base58 hashes from the pool of [i]available hashes[/i], records them in the database of [i]used hashes[/i] along with the information posted by Bob, and returns the addresses to Bob's client<br />
* Bob's client makes transactions as usual to the addresses it obtained, and publishes them in the blockchain<br />
* On the next refresh, Alice's client will contact the server and find what addresses where used, and the associated payer meta information; if the transactions exists in the blockchain, then Alice will be able to see a user friendly entry in her incoming log, that maps all 3 sends to a single entry and shows the associated payer addr and meta information, just like a regular e-wallet<br />
<br />
<br />
For maximum compatibility and easy deployment, the server works on top of DNS and HTTP, but it could be also deployed over Namecoin/Tor. It's also coin agnostic and could be implemented for any other currency besides Bitcoin. If Bob does not want to disclose his IP address to Alice's relay server, he can resolve her friendly name via Tor. It's also optional for Bob to disclose or not his own friendly address under the "payer" POST field.<br />
<br />
The system has the advantage that Mallory cannot find anything by queering the relay server. She will obtain a unique and random string that is never used in the blockchain and reveals no information about Alice. The only way to find out more is to send money to Alice and trance them further. But if Alice employs the same protocol when spending the money received from Mallory, then Mallory cannot find '''anything''' about Alice's other partners. <br />
<br />
The protocol offers the convenience of systems such as PayPal without spamming the blockchain with metadata (payment details); metadata is kept private, known only by the Bob, Alice and the server, and it can also be encrypted to exclude the server. It allows easy refund if the payer chose to disclose a return address; without the payer's friendly address, refunds to a base58 addresses are a bad ideea since there is no guarantee the sender has kept the corresponding private key.<br />
<br />
I'm not necessarily keen to have friendly addresses formatted like an email especially since this address would not have email capabilities; The friendly address syntax is yet to be defined and there are a myriad alternatives: alice$example.com, alice^example.com, btc:example.com~alice etc. I've also skimmed over the low level details for server communication since it's too early to lay down the implementation details. Also, DoS by emptying the pool of available hashes should be prevented.<br />
<br />
<br />
'''Later edit, April 03, 2012:'''<br />
<br />
The naive scheme presented above is very vulnerable to a man-in-the middle attack. Alice must trust the relay server, the DNS system, and the SSL provider of example.com; they could conspire to hand out fake keys that are not owned by Alice, seize all of Alice's funds, and log all payment details. <br />
<br />
But the sender and the recipient already have an unforgeable channel at their disposal: the blockchain. Why not use this channel to establish a trusted public key, thus widely reducing the middle man's (relay server) maneuvering capabilities ?<br />
<br />
It could go something like this:<br />
* Alice wants the friendly name alice@example.com, and the owners of example.com allow her to register it<br />
* Alice hashes the friendly name with RIPEMD160, and constructs a globally unique, unspendable bitcoin address: base58(ripemd160("alice@example.com") +checksum),<br />
* The address is unspendable since it's not a hash of a public key; only Alice and friends know this, and it cannot be detected<br />
* Alice creates a ECDSA keypair, and uses it to sign a transfer of a few bitcents to the unspendable address<br />
* Alice has just published ownership of the "alice@example.com" friendly name, with none of the Bitcoin participants seeing anything other than a regular Bitcoin transaction <br />
* Bob wants to send Alice some coins; he repeats the ripmend160 hashing and gets to the unspendable address<br />
* Bob scans his blockchain for spends to this address; it's expected the blockchain is properly indexed for such scans to be cheap<br />
* He finds the single unspent transaction made by Alice, thus obtains her public key<br />
* He contacts the relay server @example.com, and uses the Alice's ECDSA public key to cut the middle man out of the loop:<br />
* The transaction metadata is passed to the relay server as a binary blob, encrypted for Alices's private key using ECIES<br />
* Each address previously uploaded by Alice to the relay server is signed, so Bob can have full confidence Alice gets the money<br />
<br />
Using this scheme, Alice maintains good privacy (she publishes a hashed version of her address), and does not have to trust the relay server with her money or personal data. <br />
<br />
What happens if Mallory finds Alice's friendly address, and broadcasts her own transaction to base58(ripemd160("alice@example.com") +checksum), with her own public key ? Bob should accept only the first valid transaction, and ignore later ones. This has the disadvantage that if Alice looses her initial keypair, "alice@example.com" is unusable for eternity. A more complex scheme could be devised where updates, revokes and reuse can be enabled.<br />
<br />
What about address colisions ? RIPEMD160 80 bits of collision resistance should offer sufficient protection against accidental collisions; for deliberate collisions, we are exactly in the previous situations and the protocol should prevent it.<br />
<br />
There seem to be at least two similar but-incompatible schemes for doing what I proposed above as the "naive approach". Here I was thinking I am being original :):<br />
* https://en.bitcoin.it/wiki/BIP_0015<br />
* http://ecdsa.org/bitcoin_URIs.html<br />
<br />
Judging by [http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg00419.html|discussion in the mailing list], BIP15 was deferred because it lacked a clear way to authenticate the relay (alias) server. HTTPS is not enough.<br />
The electrum proposal tries to do some authentication, using an undefined "trusted authority". Not very useful.<br />
If we can define a good way to publish Alice's pubkey into the blockchain and use it further to authenticate and encrypt the exchange, we are making progress towards a working protocol. Coin destruction and spamming should be kept to a minimum or zero.<br />
<br />
==UnSpammable Publication of Friendly Address Owners' Public Keys==<br />
<br />
Using the Namecoin block-chain, it is possible for the friendly address owner to publish their pubkey for secure communication with their friendly address, without also enabling an attacker to make large numbers of desirable user accounts of a domain unavailable by publishing ownership over them in the bitcoin block-chain without the domain owner's permission. The scheme, proposed by Amincd [https://bitcointalk.org/index.php?topic=74572.msg847022#msg847022 here], would work as follows:<br />
<br />
*A relay server registers example.bit in the namecoin block-chain.<br />
*The relay server creates a base58(ripemd160("example.bit") +checksum)) hash, and sends a namecoin-bitcent/satoshi/etc to it from the namecoin address that example.bit is registered with at the time, thus publishing the pubkey of example.bit, which will be used to verify its signatures<br />
* When Alice is registering alice@example.bit, the relay server creates a digital signature for "alice@example.bit" using the privkey of the example.bit pubkey published in the namecoin block-chain, and sends it to Alice through a secure channel<br />
* Alice creates a bitcoin transaction, sending one bitcent/satoshi/etc to base58(ripemd160(example.bit-signature("alice@example.bit") +checksum)), thus publishing her public key.<br />
* When Bob wants to make a payment to alice@example.bit, he scans the namecoin block-chain for the earliest spend to base58(ripemd160("example.bit") +checksum))<br />
* He checks if the spend came from the namecoin address that example.bit was registered at at the time of the spend, and if it didn't, he looks for the next earliest spend, and does this until he finds a spend to base58(ripemd160("example.bit") +checksum)) that came from example.bit's namecoin address<br />
* Once Bob finds the spend, he considers the pubkey used for the spend as example.bit's official pubkey for signature verification<br />
* Bob asks example.bit for a digital signature of alice@example.bit, and uses example.bit's published pubkey to verify the signature was made by example.bit's official privkey<br />
* Bob scans the bitcoin block-chain for the earliest spend to base58(ripemd160(example.bit-signature("alice@example.bit") +checksum), and obtain's Alice's pubkey<br />
* There is no way the owners of example.bit could have cheated and given Bob a different signature for alice@example.bit than they gave to Alice when she published her pubkey, because every namecoin domain can only ever have one official pubkey, that can never be altered</div>Amincdhttps://en.bitcoin.it/w/index.php?title=Friendly_addresses_with_enhanced_privacy&diff=25250Friendly addresses with enhanced privacy2012-04-11T20:36:28Z<p>Amincd: /* UnSpammable Publication of Friendly Address Owners' Public Keys */</p>
<hr />
<div>The 'friendly addresses with enhanced privacy' protocol, [https://bitcointalk.org/index.php?topic=74572.0 proposed] by BubbleBoy, would provide increased privacy and improved usability in bitcoin usage. The proposal in its original form is reproduced here:<br />
<br />
==Proposal==<br />
<br />
It's my opinion that exposing a SHA256 hash to the general public is bad usability. People would much rather publish a friendly address in a format that can easily be dictated over the phone, written down or memorized, similar to the way PayPal/Skrill/Neteller work, where an email address is the identity of the account holder. They would also like to include private payment details with each transaction, such as invoice numbers, and have the option of easily providing a refund when they desire.<br />
<br />
Additionally, publishing a single base58 hash ''reduces privacy'' because it can help trace related payments to that address. A political candidate might not want to disclose the total amount of donations received. As a donor, I wouldn't want my friend and business partners to find out that some of the money they sent me ended up in a well known collection box. Since ECDSA keys are cheap, maximum privacy is achieved when each real world transaction has it's own unique address, and they are not aggregated in a master key, but rather spent individually by the recipient.<br />
<br />
Combining the two requirements, I am proposing a distributed online protocol that resolves friendly names to base58 hashes, ensuring at the same time that each transaction has it's own unique address. The protocol works using a trusted 3rd party that acts as an always-on relay point on behalf of the user, similar to an email server. The payload (money / private keys) is not under the server's control, only the public address list and their mapping to a friendly address. Privacy focused individuals who don't want to disclose even the transaction list to a 3rd party can host their own relay server.<br />
<br />
A conceptual workflow would go something like this:<br />
* Alice creates a large number of private keys and stores them offline, keeping only the public corresponding public addresses; for space concerns the private keys could be generated based on a single seed that is easy to store<br />
* Alice creates an account on the relay server, establishes an authentication token, and assigns herself a friendly address: alice@example.com <br />
* Using her authentication token, Alice's client periodically contacts the relay server and queries for recent activity related to her account ("activity" will be defined bellow); if the base58 address pool is depleted, for example on first connect, the client uploads fresh keys generated in step 1<br />
* Alice publishes her friendly address to friends, family, business partners, Bob and Mallory<br />
* When Bob desires to make a payment to Alice, he enters Alice's friendly address in his client, the amount to send, some description and any other application-specific data<br />
* Bob's client scans it's wallet and discovers it can match Bob's entered amount exactly by spending three private keys it owns<br />
* Bob's client parses the address into a server and user part, contacts the relay server via DNS/HTTP and POSTs a request for a transaction. For example the post address and data could go something like this:<br />
:POST to: https://example.com/relay_server<br />
:URL-encoded data:<br />
:user=alice&currency=BTC&amount=500&want_addr=3&description=Paycheck%20December&payer=bob@example.or:g&meta1=value1&meta2=value2&...<br />
* The relay server extracts three of Alice's base58 hashes from the pool of [i]available hashes[/i], records them in the database of [i]used hashes[/i] along with the information posted by Bob, and returns the addresses to Bob's client<br />
* Bob's client makes transactions as usual to the addresses it obtained, and publishes them in the blockchain<br />
* On the next refresh, Alice's client will contact the server and find what addresses where used, and the associated payer meta information; if the transactions exists in the blockchain, then Alice will be able to see a user friendly entry in her incoming log, that maps all 3 sends to a single entry and shows the associated payer addr and meta information, just like a regular e-wallet<br />
<br />
<br />
For maximum compatibility and easy deployment, the server works on top of DNS and HTTP, but it could be also deployed over Namecoin/Tor. It's also coin agnostic and could be implemented for any other currency besides Bitcoin. If Bob does not want to disclose his IP address to Alice's relay server, he can resolve her friendly name via Tor. It's also optional for Bob to disclose or not his own friendly address under the "payer" POST field.<br />
<br />
The system has the advantage that Mallory cannot find anything by queering the relay server. She will obtain a unique and random string that is never used in the blockchain and reveals no information about Alice. The only way to find out more is to send money to Alice and trance them further. But if Alice employs the same protocol when spending the money received from Mallory, then Mallory cannot find '''anything''' about Alice's other partners. <br />
<br />
The protocol offers the convenience of systems such as PayPal without spamming the blockchain with metadata (payment details); metadata is kept private, known only by the Bob, Alice and the server, and it can also be encrypted to exclude the server. It allows easy refund if the payer chose to disclose a return address; without the payer's friendly address, refunds to a base58 addresses are a bad ideea since there is no guarantee the sender has kept the corresponding private key.<br />
<br />
I'm not necessarily keen to have friendly addresses formatted like an email especially since this address would not have email capabilities; The friendly address syntax is yet to be defined and there are a myriad alternatives: alice$example.com, alice^example.com, btc:example.com~alice etc. I've also skimmed over the low level details for server communication since it's too early to lay down the implementation details. Also, DoS by emptying the pool of available hashes should be prevented.<br />
<br />
<br />
'''Later edit, April 03, 2012:'''<br />
<br />
The naive scheme presented above is very vulnerable to a man-in-the middle attack. Alice must trust the relay server, the DNS system, and the SSL provider of example.com; they could conspire to hand out fake keys that are not owned by Alice, seize all of Alice's funds, and log all payment details. <br />
<br />
But the sender and the recipient already have an unforgeable channel at their disposal: the blockchain. Why not use this channel to establish a trusted public key, thus widely reducing the middle man's (relay server) maneuvering capabilities ?<br />
<br />
It could go something like this:<br />
* Alice wants the friendly name alice@example.com, and the owners of example.com allow her to register it<br />
* Alice hashes the friendly name with RIPEMD160, and constructs a globally unique, unspendable bitcoin address: base58(ripemd160("alice@example.com") +checksum),<br />
* The address is unspendable since it's not a hash of a public key; only Alice and friends know this, and it cannot be detected<br />
* Alice creates a ECDSA keypair, and uses it to sign a transfer of a few bitcents to the unspendable address<br />
* Alice has just published ownership of the "alice@example.com" friendly name, with none of the Bitcoin participants seeing anything other than a regular Bitcoin transaction <br />
* Bob wants to send Alice some coins; he repeats the ripmend160 hashing and gets to the unspendable address<br />
* Bob scans his blockchain for spends to this address; it's expected the blockchain is properly indexed for such scans to be cheap<br />
* He finds the single unspent transaction made by Alice, thus obtains her public key<br />
* He contacts the relay server @example.com, and uses the Alice's ECDSA public key to cut the middle man out of the loop:<br />
* The transaction metadata is passed to the relay server as a binary blob, encrypted for Alices's private key using ECIES<br />
* Each address previously uploaded by Alice to the relay server is signed, so Bob can have full confidence Alice gets the money<br />
<br />
Using this scheme, Alice maintains good privacy (she publishes a hashed version of her address), and does not have to trust the relay server with her money or personal data. <br />
<br />
What happens if Mallory finds Alice's friendly address, and broadcasts her own transaction to base58(ripemd160("alice@example.com") +checksum), with her own public key ? Bob should accept only the first valid transaction, and ignore later ones. This has the disadvantage that if Alice looses her initial keypair, "alice@example.com" is unusable for eternity. A more complex scheme could be devised where updates, revokes and reuse can be enabled.<br />
<br />
What about address colisions ? RIPEMD160 80 bits of collision resistance should offer sufficient protection against accidental collisions; for deliberate collisions, we are exactly in the previous situations and the protocol should prevent it.<br />
<br />
There seem to be at least two similar but-incompatible schemes for doing what I proposed above as the "naive approach". Here I was thinking I am being original :):<br />
* https://en.bitcoin.it/wiki/BIP_0015<br />
* http://ecdsa.org/bitcoin_URIs.html<br />
<br />
Judging by [http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg00419.html|discussion in the mailing list], BIP15 was deferred because it lacked a clear way to authenticate the relay (alias) server. HTTPS is not enough.<br />
The electrum proposal tries to do some authentication, using an undefined "trusted authority". Not very useful.<br />
If we can define a good way to publish Alice's pubkey into the blockchain and use it further to authenticate and encrypt the exchange, we are making progress towards a working protocol. Coin destruction and spamming should be kept to a minimum or zero.<br />
<br />
==UnSpammable Publication of Friendly Address Owners' Public Keys==<br />
<br />
Using the Namecoin block-chain, it is possible for the friendly address owner to publish their pubkey for secure communication with their friendly address, without also enabling an attacker to make large numbers of desirable user accounts of a domain unavailable by publishing ownership over them in the bitcoin block-chain without the domain owner's permission. The scheme, proposed by Amincd [https://bitcointalk.org/index.php?topic=74572.msg847022#msg847022 here], would work as follows:<br />
<br />
*A relay server registers example.bit in the namecoin block-chain.<br />
*The relay server creates a base58(ripemd160("example.bit") +checksum)) hash, and sends a namecoin-bitcent/satoshi/etc to it from the namecoin address that example.bit is registered with at the time, thus publishing the pubkey of example.bit, which will be used to verify its signatures<br />
* When Alice is registering alice@example.bit, the relay server creates a digital signature for "alice@example.bit" using the privkey of the example.bit pubkey published in the namecoin block-chain, and sends it to Alice through a secure channel<br />
* Alice creates a bitcoin transaction, sending one bitcent/satoshi/etc to base58(ripemd160(example.bit-signature("alice@example.bit") +checksum)), thus publishing her public key.<br />
* When Bob wants to make a payment to alice@example.bit, he scans the namecoin block-chain for the earliest spend to base58(ripemd160("example.bit") +checksum))<br />
* He checks if the spend came from the namecoin address that example.bit was registered at at the time of the spend, and if it didn't, he looks for the next earliest spend, and does this until he finds a spend to base58(ripemd160("example.bit") +checksum)) that came from example.bit's namecoin address<br />
* Once Bob finds the spend, he considers the pubkey used for the spend as example.bit's official pubkey for signature verification<br />
* Bob asks example.bit for a digital signature of alice@example.bit, and uses example.bit's published pubkey to verify the signature was made by example.bit's official privkey<br />
* Bob scans the bitcoin block-chain for the earliest spend to base58(ripemd160(example.bit-signature("alice@example.bit") +checksum), and obtain's Alice's pubkey<br />
* There is no way the owners of example.bit could have cheated and given Bob a different signature for alice@example.bit than they gave to Alice when she published her pubkey, because every namecoin address can only ever have one official pubkey, that can never be altered</div>Amincdhttps://en.bitcoin.it/w/index.php?title=Friendly_addresses_with_enhanced_privacy&diff=25249Friendly addresses with enhanced privacy2012-04-11T20:31:42Z<p>Amincd: /* UnSpammable Publication of Friendly Address Owners' Public Keys */</p>
<hr />
<div>The 'friendly addresses with enhanced privacy' protocol, [https://bitcointalk.org/index.php?topic=74572.0 proposed] by BubbleBoy, would provide increased privacy and improved usability in bitcoin usage. The proposal in its original form is reproduced here:<br />
<br />
==Proposal==<br />
<br />
It's my opinion that exposing a SHA256 hash to the general public is bad usability. People would much rather publish a friendly address in a format that can easily be dictated over the phone, written down or memorized, similar to the way PayPal/Skrill/Neteller work, where an email address is the identity of the account holder. They would also like to include private payment details with each transaction, such as invoice numbers, and have the option of easily providing a refund when they desire.<br />
<br />
Additionally, publishing a single base58 hash ''reduces privacy'' because it can help trace related payments to that address. A political candidate might not want to disclose the total amount of donations received. As a donor, I wouldn't want my friend and business partners to find out that some of the money they sent me ended up in a well known collection box. Since ECDSA keys are cheap, maximum privacy is achieved when each real world transaction has it's own unique address, and they are not aggregated in a master key, but rather spent individually by the recipient.<br />
<br />
Combining the two requirements, I am proposing a distributed online protocol that resolves friendly names to base58 hashes, ensuring at the same time that each transaction has it's own unique address. The protocol works using a trusted 3rd party that acts as an always-on relay point on behalf of the user, similar to an email server. The payload (money / private keys) is not under the server's control, only the public address list and their mapping to a friendly address. Privacy focused individuals who don't want to disclose even the transaction list to a 3rd party can host their own relay server.<br />
<br />
A conceptual workflow would go something like this:<br />
* Alice creates a large number of private keys and stores them offline, keeping only the public corresponding public addresses; for space concerns the private keys could be generated based on a single seed that is easy to store<br />
* Alice creates an account on the relay server, establishes an authentication token, and assigns herself a friendly address: alice@example.com <br />
* Using her authentication token, Alice's client periodically contacts the relay server and queries for recent activity related to her account ("activity" will be defined bellow); if the base58 address pool is depleted, for example on first connect, the client uploads fresh keys generated in step 1<br />
* Alice publishes her friendly address to friends, family, business partners, Bob and Mallory<br />
* When Bob desires to make a payment to Alice, he enters Alice's friendly address in his client, the amount to send, some description and any other application-specific data<br />
* Bob's client scans it's wallet and discovers it can match Bob's entered amount exactly by spending three private keys it owns<br />
* Bob's client parses the address into a server and user part, contacts the relay server via DNS/HTTP and POSTs a request for a transaction. For example the post address and data could go something like this:<br />
:POST to: https://example.com/relay_server<br />
:URL-encoded data:<br />
:user=alice&currency=BTC&amount=500&want_addr=3&description=Paycheck%20December&payer=bob@example.or:g&meta1=value1&meta2=value2&...<br />
* The relay server extracts three of Alice's base58 hashes from the pool of [i]available hashes[/i], records them in the database of [i]used hashes[/i] along with the information posted by Bob, and returns the addresses to Bob's client<br />
* Bob's client makes transactions as usual to the addresses it obtained, and publishes them in the blockchain<br />
* On the next refresh, Alice's client will contact the server and find what addresses where used, and the associated payer meta information; if the transactions exists in the blockchain, then Alice will be able to see a user friendly entry in her incoming log, that maps all 3 sends to a single entry and shows the associated payer addr and meta information, just like a regular e-wallet<br />
<br />
<br />
For maximum compatibility and easy deployment, the server works on top of DNS and HTTP, but it could be also deployed over Namecoin/Tor. It's also coin agnostic and could be implemented for any other currency besides Bitcoin. If Bob does not want to disclose his IP address to Alice's relay server, he can resolve her friendly name via Tor. It's also optional for Bob to disclose or not his own friendly address under the "payer" POST field.<br />
<br />
The system has the advantage that Mallory cannot find anything by queering the relay server. She will obtain a unique and random string that is never used in the blockchain and reveals no information about Alice. The only way to find out more is to send money to Alice and trance them further. But if Alice employs the same protocol when spending the money received from Mallory, then Mallory cannot find '''anything''' about Alice's other partners. <br />
<br />
The protocol offers the convenience of systems such as PayPal without spamming the blockchain with metadata (payment details); metadata is kept private, known only by the Bob, Alice and the server, and it can also be encrypted to exclude the server. It allows easy refund if the payer chose to disclose a return address; without the payer's friendly address, refunds to a base58 addresses are a bad ideea since there is no guarantee the sender has kept the corresponding private key.<br />
<br />
I'm not necessarily keen to have friendly addresses formatted like an email especially since this address would not have email capabilities; The friendly address syntax is yet to be defined and there are a myriad alternatives: alice$example.com, alice^example.com, btc:example.com~alice etc. I've also skimmed over the low level details for server communication since it's too early to lay down the implementation details. Also, DoS by emptying the pool of available hashes should be prevented.<br />
<br />
<br />
'''Later edit, April 03, 2012:'''<br />
<br />
The naive scheme presented above is very vulnerable to a man-in-the middle attack. Alice must trust the relay server, the DNS system, and the SSL provider of example.com; they could conspire to hand out fake keys that are not owned by Alice, seize all of Alice's funds, and log all payment details. <br />
<br />
But the sender and the recipient already have an unforgeable channel at their disposal: the blockchain. Why not use this channel to establish a trusted public key, thus widely reducing the middle man's (relay server) maneuvering capabilities ?<br />
<br />
It could go something like this:<br />
* Alice wants the friendly name alice@example.com, and the owners of example.com allow her to register it<br />
* Alice hashes the friendly name with RIPEMD160, and constructs a globally unique, unspendable bitcoin address: base58(ripemd160("alice@example.com") +checksum),<br />
* The address is unspendable since it's not a hash of a public key; only Alice and friends know this, and it cannot be detected<br />
* Alice creates a ECDSA keypair, and uses it to sign a transfer of a few bitcents to the unspendable address<br />
* Alice has just published ownership of the "alice@example.com" friendly name, with none of the Bitcoin participants seeing anything other than a regular Bitcoin transaction <br />
* Bob wants to send Alice some coins; he repeats the ripmend160 hashing and gets to the unspendable address<br />
* Bob scans his blockchain for spends to this address; it's expected the blockchain is properly indexed for such scans to be cheap<br />
* He finds the single unspent transaction made by Alice, thus obtains her public key<br />
* He contacts the relay server @example.com, and uses the Alice's ECDSA public key to cut the middle man out of the loop:<br />
* The transaction metadata is passed to the relay server as a binary blob, encrypted for Alices's private key using ECIES<br />
* Each address previously uploaded by Alice to the relay server is signed, so Bob can have full confidence Alice gets the money<br />
<br />
Using this scheme, Alice maintains good privacy (she publishes a hashed version of her address), and does not have to trust the relay server with her money or personal data. <br />
<br />
What happens if Mallory finds Alice's friendly address, and broadcasts her own transaction to base58(ripemd160("alice@example.com") +checksum), with her own public key ? Bob should accept only the first valid transaction, and ignore later ones. This has the disadvantage that if Alice looses her initial keypair, "alice@example.com" is unusable for eternity. A more complex scheme could be devised where updates, revokes and reuse can be enabled.<br />
<br />
What about address colisions ? RIPEMD160 80 bits of collision resistance should offer sufficient protection against accidental collisions; for deliberate collisions, we are exactly in the previous situations and the protocol should prevent it.<br />
<br />
There seem to be at least two similar but-incompatible schemes for doing what I proposed above as the "naive approach". Here I was thinking I am being original :):<br />
* https://en.bitcoin.it/wiki/BIP_0015<br />
* http://ecdsa.org/bitcoin_URIs.html<br />
<br />
Judging by [http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg00419.html|discussion in the mailing list], BIP15 was deferred because it lacked a clear way to authenticate the relay (alias) server. HTTPS is not enough.<br />
The electrum proposal tries to do some authentication, using an undefined "trusted authority". Not very useful.<br />
If we can define a good way to publish Alice's pubkey into the blockchain and use it further to authenticate and encrypt the exchange, we are making progress towards a working protocol. Coin destruction and spamming should be kept to a minimum or zero.<br />
<br />
==UnSpammable Publication of Friendly Address Owners' Public Keys==<br />
<br />
Using the Namecoin block-chain, it is possible for the friendly address owner to publish their pubkey for secure communication with their friendly address, without also enabling an attacker to make large numbers of desirable user accounts of domains unavailable by publishing ownership over them without the domain owner's permission in the bitcoin block-chain. The scheme, proposed by Amincd [https://bitcointalk.org/index.php?topic=74572.msg847022#msg847022 here], would work as follows:<br />
<br />
*A relay server registers example.bit in the namecoin block-chain.<br />
*The relay server creates a base58(ripemd160("example.bit") +checksum)) hash, and sends a namecoin-bitcent/satoshi/etc to it from the namecoin address that example.bit is registered with at the time, thus publishing the pubkey of example.bit, which will be used to verify its signatures<br />
* When Alice is registering alice@example.bit, the relay server creates a digital signature for "alice@example.bit" using the privkey of the example.bit pubkey published in the namecoin block-chain, and sends it to Alice through a secure channel<br />
* Alice creates a bitcoin transaction, sending one bitcent/satoshi/etc to base58(ripemd160(example.bit-signature("alice@example.bit") +checksum)), thus publishing her public key.<br />
* When Bob wants to make a payment to alice@example.bit, he scans the namecoin block-chain for the earliest spend to base58(ripemd160("example.bit") +checksum))<br />
* He checks if the spend came from the namecoin address that example.bit was registered at at the time of the spend, and if it didn't, he looks for the next earliest spend, and does this until he finds a spend to base58(ripemd160("example.bit") +checksum)) that came from example.bit's namecoin address<br />
* Once Bob finds the spend, he considers the pubkey used for the spend as example.bit's official pubkey for signature verification<br />
* Bob asks example.bit for a digital signature of alice@example.bit, and uses example.bit's published pubkey to verify the signature was made by example.bit's official privkey<br />
* Bob scans the bitcoin block-chain for the earliest spend to base58(ripemd160(example.bit-signature("alice@example.bit") +checksum), and obtain's Alice's pubkey<br />
* There is no way the owners of example.bit could have cheated and given Bob a different signature for alice@example.bit than they gave to Alice when she published her pubkey, because every namecoin address can only ever have one official pubkey, that can never be altered</div>Amincdhttps://en.bitcoin.it/w/index.php?title=Friendly_addresses_with_enhanced_privacy&diff=25248Friendly addresses with enhanced privacy2012-04-11T20:25:53Z<p>Amincd: /* UnSpammable Publication of Friendly Address Owners' Public Keys */</p>
<hr />
<div>The 'friendly addresses with enhanced privacy' protocol, [https://bitcointalk.org/index.php?topic=74572.0 proposed] by BubbleBoy, would provide increased privacy and improved usability in bitcoin usage. The proposal in its original form is reproduced here:<br />
<br />
==Proposal==<br />
<br />
It's my opinion that exposing a SHA256 hash to the general public is bad usability. People would much rather publish a friendly address in a format that can easily be dictated over the phone, written down or memorized, similar to the way PayPal/Skrill/Neteller work, where an email address is the identity of the account holder. They would also like to include private payment details with each transaction, such as invoice numbers, and have the option of easily providing a refund when they desire.<br />
<br />
Additionally, publishing a single base58 hash ''reduces privacy'' because it can help trace related payments to that address. A political candidate might not want to disclose the total amount of donations received. As a donor, I wouldn't want my friend and business partners to find out that some of the money they sent me ended up in a well known collection box. Since ECDSA keys are cheap, maximum privacy is achieved when each real world transaction has it's own unique address, and they are not aggregated in a master key, but rather spent individually by the recipient.<br />
<br />
Combining the two requirements, I am proposing a distributed online protocol that resolves friendly names to base58 hashes, ensuring at the same time that each transaction has it's own unique address. The protocol works using a trusted 3rd party that acts as an always-on relay point on behalf of the user, similar to an email server. The payload (money / private keys) is not under the server's control, only the public address list and their mapping to a friendly address. Privacy focused individuals who don't want to disclose even the transaction list to a 3rd party can host their own relay server.<br />
<br />
A conceptual workflow would go something like this:<br />
* Alice creates a large number of private keys and stores them offline, keeping only the public corresponding public addresses; for space concerns the private keys could be generated based on a single seed that is easy to store<br />
* Alice creates an account on the relay server, establishes an authentication token, and assigns herself a friendly address: alice@example.com <br />
* Using her authentication token, Alice's client periodically contacts the relay server and queries for recent activity related to her account ("activity" will be defined bellow); if the base58 address pool is depleted, for example on first connect, the client uploads fresh keys generated in step 1<br />
* Alice publishes her friendly address to friends, family, business partners, Bob and Mallory<br />
* When Bob desires to make a payment to Alice, he enters Alice's friendly address in his client, the amount to send, some description and any other application-specific data<br />
* Bob's client scans it's wallet and discovers it can match Bob's entered amount exactly by spending three private keys it owns<br />
* Bob's client parses the address into a server and user part, contacts the relay server via DNS/HTTP and POSTs a request for a transaction. For example the post address and data could go something like this:<br />
:POST to: https://example.com/relay_server<br />
:URL-encoded data:<br />
:user=alice&currency=BTC&amount=500&want_addr=3&description=Paycheck%20December&payer=bob@example.or:g&meta1=value1&meta2=value2&...<br />
* The relay server extracts three of Alice's base58 hashes from the pool of [i]available hashes[/i], records them in the database of [i]used hashes[/i] along with the information posted by Bob, and returns the addresses to Bob's client<br />
* Bob's client makes transactions as usual to the addresses it obtained, and publishes them in the blockchain<br />
* On the next refresh, Alice's client will contact the server and find what addresses where used, and the associated payer meta information; if the transactions exists in the blockchain, then Alice will be able to see a user friendly entry in her incoming log, that maps all 3 sends to a single entry and shows the associated payer addr and meta information, just like a regular e-wallet<br />
<br />
<br />
For maximum compatibility and easy deployment, the server works on top of DNS and HTTP, but it could be also deployed over Namecoin/Tor. It's also coin agnostic and could be implemented for any other currency besides Bitcoin. If Bob does not want to disclose his IP address to Alice's relay server, he can resolve her friendly name via Tor. It's also optional for Bob to disclose or not his own friendly address under the "payer" POST field.<br />
<br />
The system has the advantage that Mallory cannot find anything by queering the relay server. She will obtain a unique and random string that is never used in the blockchain and reveals no information about Alice. The only way to find out more is to send money to Alice and trance them further. But if Alice employs the same protocol when spending the money received from Mallory, then Mallory cannot find '''anything''' about Alice's other partners. <br />
<br />
The protocol offers the convenience of systems such as PayPal without spamming the blockchain with metadata (payment details); metadata is kept private, known only by the Bob, Alice and the server, and it can also be encrypted to exclude the server. It allows easy refund if the payer chose to disclose a return address; without the payer's friendly address, refunds to a base58 addresses are a bad ideea since there is no guarantee the sender has kept the corresponding private key.<br />
<br />
I'm not necessarily keen to have friendly addresses formatted like an email especially since this address would not have email capabilities; The friendly address syntax is yet to be defined and there are a myriad alternatives: alice$example.com, alice^example.com, btc:example.com~alice etc. I've also skimmed over the low level details for server communication since it's too early to lay down the implementation details. Also, DoS by emptying the pool of available hashes should be prevented.<br />
<br />
<br />
'''Later edit, April 03, 2012:'''<br />
<br />
The naive scheme presented above is very vulnerable to a man-in-the middle attack. Alice must trust the relay server, the DNS system, and the SSL provider of example.com; they could conspire to hand out fake keys that are not owned by Alice, seize all of Alice's funds, and log all payment details. <br />
<br />
But the sender and the recipient already have an unforgeable channel at their disposal: the blockchain. Why not use this channel to establish a trusted public key, thus widely reducing the middle man's (relay server) maneuvering capabilities ?<br />
<br />
It could go something like this:<br />
* Alice wants the friendly name alice@example.com, and the owners of example.com allow her to register it<br />
* Alice hashes the friendly name with RIPEMD160, and constructs a globally unique, unspendable bitcoin address: base58(ripemd160("alice@example.com") +checksum),<br />
* The address is unspendable since it's not a hash of a public key; only Alice and friends know this, and it cannot be detected<br />
* Alice creates a ECDSA keypair, and uses it to sign a transfer of a few bitcents to the unspendable address<br />
* Alice has just published ownership of the "alice@example.com" friendly name, with none of the Bitcoin participants seeing anything other than a regular Bitcoin transaction <br />
* Bob wants to send Alice some coins; he repeats the ripmend160 hashing and gets to the unspendable address<br />
* Bob scans his blockchain for spends to this address; it's expected the blockchain is properly indexed for such scans to be cheap<br />
* He finds the single unspent transaction made by Alice, thus obtains her public key<br />
* He contacts the relay server @example.com, and uses the Alice's ECDSA public key to cut the middle man out of the loop:<br />
* The transaction metadata is passed to the relay server as a binary blob, encrypted for Alices's private key using ECIES<br />
* Each address previously uploaded by Alice to the relay server is signed, so Bob can have full confidence Alice gets the money<br />
<br />
Using this scheme, Alice maintains good privacy (she publishes a hashed version of her address), and does not have to trust the relay server with her money or personal data. <br />
<br />
What happens if Mallory finds Alice's friendly address, and broadcasts her own transaction to base58(ripemd160("alice@example.com") +checksum), with her own public key ? Bob should accept only the first valid transaction, and ignore later ones. This has the disadvantage that if Alice looses her initial keypair, "alice@example.com" is unusable for eternity. A more complex scheme could be devised where updates, revokes and reuse can be enabled.<br />
<br />
What about address colisions ? RIPEMD160 80 bits of collision resistance should offer sufficient protection against accidental collisions; for deliberate collisions, we are exactly in the previous situations and the protocol should prevent it.<br />
<br />
There seem to be at least two similar but-incompatible schemes for doing what I proposed above as the "naive approach". Here I was thinking I am being original :):<br />
* https://en.bitcoin.it/wiki/BIP_0015<br />
* http://ecdsa.org/bitcoin_URIs.html<br />
<br />
Judging by [http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg00419.html|discussion in the mailing list], BIP15 was deferred because it lacked a clear way to authenticate the relay (alias) server. HTTPS is not enough.<br />
The electrum proposal tries to do some authentication, using an undefined "trusted authority". Not very useful.<br />
If we can define a good way to publish Alice's pubkey into the blockchain and use it further to authenticate and encrypt the exchange, we are making progress towards a working protocol. Coin destruction and spamming should be kept to a minimum or zero.<br />
<br />
==UnSpammable Publication of Friendly Address Owners' Public Keys==<br />
<br />
Using the Namecoin block-chain, it is possible for the sender to publish their pubkey for secure communication with their friendly address, without also enabling an attacker to make large numbers of desirable user accounts of domains unavailable by publishing ownership over them without the domain owner's permission in the bitcoin block-chain. The scheme, proposed by Amincd [https://bitcointalk.org/index.php?topic=74572.msg847022#msg847022 here], would work as follows:<br />
<br />
*A relay server registers example.bit in the namecoin block-chain.<br />
*The relay server creates a base58(ripemd160("example.bit") +checksum)) hash, and sends a namecoin-bitcent/satoshi/etc to it from the namecoin address that example.bit is registered with at the time, thus publishing the pubkey of example.bit, which will be used to verify its signatures<br />
* When Alice is registering alice@example.bit, the relay server creates a digital signature for "alice@example.bit" using the privkey of the example.bit pubkey published in the namecoin block-chain, and sends it to Alice through a secure channel<br />
* Alice creates a bitcoin transaction, sending one bitcent/satoshi/etc to base58(ripemd160(example.bit-signature("alice@example.bit") +checksum)), thus publishing her public key.<br />
* When Bob wants to make a payment to alice@example.bit, he scans the namecoin block-chain for the earliest spend to base58(ripemd160("example.bit") +checksum))<br />
* He checks if the spend came from the namecoin address that example.bit was registered at at the time of the spend, and if it didn't, he looks for the next earliest spend, and does this until he finds a spend to base58(ripemd160("example.bit") +checksum)) that came from example.bit's namecoin address<br />
* Once Bob finds the spend, he considers the pubkey used for the spend as example.bit's official pubkey for signature verification<br />
* Bob asks example.bit for a digital signature of alice@example.bit, and uses example.bit's published pubkey to verify the signature was made by example.bit's official privkey<br />
* Bob scans the bitcoin block-chain for the earliest spend to base58(ripemd160(example.bit-signature("alice@example.bit") +checksum), and obtain's Alice's pubkey<br />
* There is no way the owners of example.bit could have cheated and given Bob a different signature for alice@example.bit than they gave to Alice when she published her pubkey, because every namecoin address can only ever have one official pubkey, that can never be altered</div>Amincdhttps://en.bitcoin.it/w/index.php?title=Friendly_addresses_with_enhanced_privacy&diff=25247Friendly addresses with enhanced privacy2012-04-11T20:25:02Z<p>Amincd: /* UnSpammable Publication of Senders' Public Keys */</p>
<hr />
<div>The 'friendly addresses with enhanced privacy' protocol, [https://bitcointalk.org/index.php?topic=74572.0 proposed] by BubbleBoy, would provide increased privacy and improved usability in bitcoin usage. The proposal in its original form is reproduced here:<br />
<br />
==Proposal==<br />
<br />
It's my opinion that exposing a SHA256 hash to the general public is bad usability. People would much rather publish a friendly address in a format that can easily be dictated over the phone, written down or memorized, similar to the way PayPal/Skrill/Neteller work, where an email address is the identity of the account holder. They would also like to include private payment details with each transaction, such as invoice numbers, and have the option of easily providing a refund when they desire.<br />
<br />
Additionally, publishing a single base58 hash ''reduces privacy'' because it can help trace related payments to that address. A political candidate might not want to disclose the total amount of donations received. As a donor, I wouldn't want my friend and business partners to find out that some of the money they sent me ended up in a well known collection box. Since ECDSA keys are cheap, maximum privacy is achieved when each real world transaction has it's own unique address, and they are not aggregated in a master key, but rather spent individually by the recipient.<br />
<br />
Combining the two requirements, I am proposing a distributed online protocol that resolves friendly names to base58 hashes, ensuring at the same time that each transaction has it's own unique address. The protocol works using a trusted 3rd party that acts as an always-on relay point on behalf of the user, similar to an email server. The payload (money / private keys) is not under the server's control, only the public address list and their mapping to a friendly address. Privacy focused individuals who don't want to disclose even the transaction list to a 3rd party can host their own relay server.<br />
<br />
A conceptual workflow would go something like this:<br />
* Alice creates a large number of private keys and stores them offline, keeping only the public corresponding public addresses; for space concerns the private keys could be generated based on a single seed that is easy to store<br />
* Alice creates an account on the relay server, establishes an authentication token, and assigns herself a friendly address: alice@example.com <br />
* Using her authentication token, Alice's client periodically contacts the relay server and queries for recent activity related to her account ("activity" will be defined bellow); if the base58 address pool is depleted, for example on first connect, the client uploads fresh keys generated in step 1<br />
* Alice publishes her friendly address to friends, family, business partners, Bob and Mallory<br />
* When Bob desires to make a payment to Alice, he enters Alice's friendly address in his client, the amount to send, some description and any other application-specific data<br />
* Bob's client scans it's wallet and discovers it can match Bob's entered amount exactly by spending three private keys it owns<br />
* Bob's client parses the address into a server and user part, contacts the relay server via DNS/HTTP and POSTs a request for a transaction. For example the post address and data could go something like this:<br />
:POST to: https://example.com/relay_server<br />
:URL-encoded data:<br />
:user=alice&currency=BTC&amount=500&want_addr=3&description=Paycheck%20December&payer=bob@example.or:g&meta1=value1&meta2=value2&...<br />
* The relay server extracts three of Alice's base58 hashes from the pool of [i]available hashes[/i], records them in the database of [i]used hashes[/i] along with the information posted by Bob, and returns the addresses to Bob's client<br />
* Bob's client makes transactions as usual to the addresses it obtained, and publishes them in the blockchain<br />
* On the next refresh, Alice's client will contact the server and find what addresses where used, and the associated payer meta information; if the transactions exists in the blockchain, then Alice will be able to see a user friendly entry in her incoming log, that maps all 3 sends to a single entry and shows the associated payer addr and meta information, just like a regular e-wallet<br />
<br />
<br />
For maximum compatibility and easy deployment, the server works on top of DNS and HTTP, but it could be also deployed over Namecoin/Tor. It's also coin agnostic and could be implemented for any other currency besides Bitcoin. If Bob does not want to disclose his IP address to Alice's relay server, he can resolve her friendly name via Tor. It's also optional for Bob to disclose or not his own friendly address under the "payer" POST field.<br />
<br />
The system has the advantage that Mallory cannot find anything by queering the relay server. She will obtain a unique and random string that is never used in the blockchain and reveals no information about Alice. The only way to find out more is to send money to Alice and trance them further. But if Alice employs the same protocol when spending the money received from Mallory, then Mallory cannot find '''anything''' about Alice's other partners. <br />
<br />
The protocol offers the convenience of systems such as PayPal without spamming the blockchain with metadata (payment details); metadata is kept private, known only by the Bob, Alice and the server, and it can also be encrypted to exclude the server. It allows easy refund if the payer chose to disclose a return address; without the payer's friendly address, refunds to a base58 addresses are a bad ideea since there is no guarantee the sender has kept the corresponding private key.<br />
<br />
I'm not necessarily keen to have friendly addresses formatted like an email especially since this address would not have email capabilities; The friendly address syntax is yet to be defined and there are a myriad alternatives: alice$example.com, alice^example.com, btc:example.com~alice etc. I've also skimmed over the low level details for server communication since it's too early to lay down the implementation details. Also, DoS by emptying the pool of available hashes should be prevented.<br />
<br />
<br />
'''Later edit, April 03, 2012:'''<br />
<br />
The naive scheme presented above is very vulnerable to a man-in-the middle attack. Alice must trust the relay server, the DNS system, and the SSL provider of example.com; they could conspire to hand out fake keys that are not owned by Alice, seize all of Alice's funds, and log all payment details. <br />
<br />
But the sender and the recipient already have an unforgeable channel at their disposal: the blockchain. Why not use this channel to establish a trusted public key, thus widely reducing the middle man's (relay server) maneuvering capabilities ?<br />
<br />
It could go something like this:<br />
* Alice wants the friendly name alice@example.com, and the owners of example.com allow her to register it<br />
* Alice hashes the friendly name with RIPEMD160, and constructs a globally unique, unspendable bitcoin address: base58(ripemd160("alice@example.com") +checksum),<br />
* The address is unspendable since it's not a hash of a public key; only Alice and friends know this, and it cannot be detected<br />
* Alice creates a ECDSA keypair, and uses it to sign a transfer of a few bitcents to the unspendable address<br />
* Alice has just published ownership of the "alice@example.com" friendly name, with none of the Bitcoin participants seeing anything other than a regular Bitcoin transaction <br />
* Bob wants to send Alice some coins; he repeats the ripmend160 hashing and gets to the unspendable address<br />
* Bob scans his blockchain for spends to this address; it's expected the blockchain is properly indexed for such scans to be cheap<br />
* He finds the single unspent transaction made by Alice, thus obtains her public key<br />
* He contacts the relay server @example.com, and uses the Alice's ECDSA public key to cut the middle man out of the loop:<br />
* The transaction metadata is passed to the relay server as a binary blob, encrypted for Alices's private key using ECIES<br />
* Each address previously uploaded by Alice to the relay server is signed, so Bob can have full confidence Alice gets the money<br />
<br />
Using this scheme, Alice maintains good privacy (she publishes a hashed version of her address), and does not have to trust the relay server with her money or personal data. <br />
<br />
What happens if Mallory finds Alice's friendly address, and broadcasts her own transaction to base58(ripemd160("alice@example.com") +checksum), with her own public key ? Bob should accept only the first valid transaction, and ignore later ones. This has the disadvantage that if Alice looses her initial keypair, "alice@example.com" is unusable for eternity. A more complex scheme could be devised where updates, revokes and reuse can be enabled.<br />
<br />
What about address colisions ? RIPEMD160 80 bits of collision resistance should offer sufficient protection against accidental collisions; for deliberate collisions, we are exactly in the previous situations and the protocol should prevent it.<br />
<br />
There seem to be at least two similar but-incompatible schemes for doing what I proposed above as the "naive approach". Here I was thinking I am being original :):<br />
* https://en.bitcoin.it/wiki/BIP_0015<br />
* http://ecdsa.org/bitcoin_URIs.html<br />
<br />
Judging by [http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg00419.html|discussion in the mailing list], BIP15 was deferred because it lacked a clear way to authenticate the relay (alias) server. HTTPS is not enough.<br />
The electrum proposal tries to do some authentication, using an undefined "trusted authority". Not very useful.<br />
If we can define a good way to publish Alice's pubkey into the blockchain and use it further to authenticate and encrypt the exchange, we are making progress towards a working protocol. Coin destruction and spamming should be kept to a minimum or zero.<br />
<br />
==UnSpammable Publication of Friendly Address Owners' Public Keys==<br />
<br />
Using the Namecoin block-chain, it is possible for the sender to publish their pubkey for secure communication with their friendly address, without also enabling an attacker to make large numbers of desirable user accounts of domains unavailable by publishing ownership over them without the domain owner's permission in the bitcoin block-chain. The scheme, proposed [https://bitcointalk.org/index.php?topic=74572.msg847022#msg847022 here], would work as follows:<br />
<br />
*A relay server registers example.bit in the namecoin block-chain.<br />
*The relay server creates a base58(ripemd160("example.bit") +checksum)) hash, and sends a namecoin-bitcent/satoshi/etc to it from the namecoin address that example.bit is registered with at the time, thus publishing the pubkey of example.bit, which will be used to verify its signatures<br />
* When Alice is registering alice@example.bit, the relay server creates a digital signature for "alice@example.bit" using the privkey of the example.bit pubkey published in the namecoin block-chain, and sends it to Alice through a secure channel<br />
* Alice creates a bitcoin transaction, sending one bitcent/satoshi/etc to base58(ripemd160(example.bit-signature("alice@example.bit") +checksum)), thus publishing her public key.<br />
* When Bob wants to make a payment to alice@example.bit, he scans the namecoin block-chain for the earliest spend to base58(ripemd160("example.bit") +checksum))<br />
* He checks if the spend came from the namecoin address that example.bit was registered at at the time of the spend, and if it didn't, he looks for the next earliest spend, and does this until he finds a spend to base58(ripemd160("example.bit") +checksum)) that came from example.bit's namecoin address<br />
* Once Bob finds the spend, he considers the pubkey used for the spend as example.bit's official pubkey for signature verification<br />
* Bob asks example.bit for a digital signature of alice@example.bit, and uses example.bit's published pubkey to verify the signature was made by example.bit's official privkey<br />
* Bob scans the bitcoin block-chain for the earliest spend to base58(ripemd160(example.bit-signature("alice@example.bit") +checksum), and obtain's Alice's pubkey<br />
* There is no way the owners of example.bit could have cheated and given Bob a different signature for alice@example.bit than they gave to Alice when she published her pubkey, because every namecoin address can only ever have one official pubkey, that can never be altered</div>Amincdhttps://en.bitcoin.it/w/index.php?title=Friendly_addresses_with_enhanced_privacy&diff=25246Friendly addresses with enhanced privacy2012-04-11T20:23:25Z<p>Amincd: /* UnSpammable Publication of Senders' Public Keys */</p>
<hr />
<div>The 'friendly addresses with enhanced privacy' protocol, [https://bitcointalk.org/index.php?topic=74572.0 proposed] by BubbleBoy, would provide increased privacy and improved usability in bitcoin usage. The proposal in its original form is reproduced here:<br />
<br />
==Proposal==<br />
<br />
It's my opinion that exposing a SHA256 hash to the general public is bad usability. People would much rather publish a friendly address in a format that can easily be dictated over the phone, written down or memorized, similar to the way PayPal/Skrill/Neteller work, where an email address is the identity of the account holder. They would also like to include private payment details with each transaction, such as invoice numbers, and have the option of easily providing a refund when they desire.<br />
<br />
Additionally, publishing a single base58 hash ''reduces privacy'' because it can help trace related payments to that address. A political candidate might not want to disclose the total amount of donations received. As a donor, I wouldn't want my friend and business partners to find out that some of the money they sent me ended up in a well known collection box. Since ECDSA keys are cheap, maximum privacy is achieved when each real world transaction has it's own unique address, and they are not aggregated in a master key, but rather spent individually by the recipient.<br />
<br />
Combining the two requirements, I am proposing a distributed online protocol that resolves friendly names to base58 hashes, ensuring at the same time that each transaction has it's own unique address. The protocol works using a trusted 3rd party that acts as an always-on relay point on behalf of the user, similar to an email server. The payload (money / private keys) is not under the server's control, only the public address list and their mapping to a friendly address. Privacy focused individuals who don't want to disclose even the transaction list to a 3rd party can host their own relay server.<br />
<br />
A conceptual workflow would go something like this:<br />
* Alice creates a large number of private keys and stores them offline, keeping only the public corresponding public addresses; for space concerns the private keys could be generated based on a single seed that is easy to store<br />
* Alice creates an account on the relay server, establishes an authentication token, and assigns herself a friendly address: alice@example.com <br />
* Using her authentication token, Alice's client periodically contacts the relay server and queries for recent activity related to her account ("activity" will be defined bellow); if the base58 address pool is depleted, for example on first connect, the client uploads fresh keys generated in step 1<br />
* Alice publishes her friendly address to friends, family, business partners, Bob and Mallory<br />
* When Bob desires to make a payment to Alice, he enters Alice's friendly address in his client, the amount to send, some description and any other application-specific data<br />
* Bob's client scans it's wallet and discovers it can match Bob's entered amount exactly by spending three private keys it owns<br />
* Bob's client parses the address into a server and user part, contacts the relay server via DNS/HTTP and POSTs a request for a transaction. For example the post address and data could go something like this:<br />
:POST to: https://example.com/relay_server<br />
:URL-encoded data:<br />
:user=alice&currency=BTC&amount=500&want_addr=3&description=Paycheck%20December&payer=bob@example.or:g&meta1=value1&meta2=value2&...<br />
* The relay server extracts three of Alice's base58 hashes from the pool of [i]available hashes[/i], records them in the database of [i]used hashes[/i] along with the information posted by Bob, and returns the addresses to Bob's client<br />
* Bob's client makes transactions as usual to the addresses it obtained, and publishes them in the blockchain<br />
* On the next refresh, Alice's client will contact the server and find what addresses where used, and the associated payer meta information; if the transactions exists in the blockchain, then Alice will be able to see a user friendly entry in her incoming log, that maps all 3 sends to a single entry and shows the associated payer addr and meta information, just like a regular e-wallet<br />
<br />
<br />
For maximum compatibility and easy deployment, the server works on top of DNS and HTTP, but it could be also deployed over Namecoin/Tor. It's also coin agnostic and could be implemented for any other currency besides Bitcoin. If Bob does not want to disclose his IP address to Alice's relay server, he can resolve her friendly name via Tor. It's also optional for Bob to disclose or not his own friendly address under the "payer" POST field.<br />
<br />
The system has the advantage that Mallory cannot find anything by queering the relay server. She will obtain a unique and random string that is never used in the blockchain and reveals no information about Alice. The only way to find out more is to send money to Alice and trance them further. But if Alice employs the same protocol when spending the money received from Mallory, then Mallory cannot find '''anything''' about Alice's other partners. <br />
<br />
The protocol offers the convenience of systems such as PayPal without spamming the blockchain with metadata (payment details); metadata is kept private, known only by the Bob, Alice and the server, and it can also be encrypted to exclude the server. It allows easy refund if the payer chose to disclose a return address; without the payer's friendly address, refunds to a base58 addresses are a bad ideea since there is no guarantee the sender has kept the corresponding private key.<br />
<br />
I'm not necessarily keen to have friendly addresses formatted like an email especially since this address would not have email capabilities; The friendly address syntax is yet to be defined and there are a myriad alternatives: alice$example.com, alice^example.com, btc:example.com~alice etc. I've also skimmed over the low level details for server communication since it's too early to lay down the implementation details. Also, DoS by emptying the pool of available hashes should be prevented.<br />
<br />
<br />
'''Later edit, April 03, 2012:'''<br />
<br />
The naive scheme presented above is very vulnerable to a man-in-the middle attack. Alice must trust the relay server, the DNS system, and the SSL provider of example.com; they could conspire to hand out fake keys that are not owned by Alice, seize all of Alice's funds, and log all payment details. <br />
<br />
But the sender and the recipient already have an unforgeable channel at their disposal: the blockchain. Why not use this channel to establish a trusted public key, thus widely reducing the middle man's (relay server) maneuvering capabilities ?<br />
<br />
It could go something like this:<br />
* Alice wants the friendly name alice@example.com, and the owners of example.com allow her to register it<br />
* Alice hashes the friendly name with RIPEMD160, and constructs a globally unique, unspendable bitcoin address: base58(ripemd160("alice@example.com") +checksum),<br />
* The address is unspendable since it's not a hash of a public key; only Alice and friends know this, and it cannot be detected<br />
* Alice creates a ECDSA keypair, and uses it to sign a transfer of a few bitcents to the unspendable address<br />
* Alice has just published ownership of the "alice@example.com" friendly name, with none of the Bitcoin participants seeing anything other than a regular Bitcoin transaction <br />
* Bob wants to send Alice some coins; he repeats the ripmend160 hashing and gets to the unspendable address<br />
* Bob scans his blockchain for spends to this address; it's expected the blockchain is properly indexed for such scans to be cheap<br />
* He finds the single unspent transaction made by Alice, thus obtains her public key<br />
* He contacts the relay server @example.com, and uses the Alice's ECDSA public key to cut the middle man out of the loop:<br />
* The transaction metadata is passed to the relay server as a binary blob, encrypted for Alices's private key using ECIES<br />
* Each address previously uploaded by Alice to the relay server is signed, so Bob can have full confidence Alice gets the money<br />
<br />
Using this scheme, Alice maintains good privacy (she publishes a hashed version of her address), and does not have to trust the relay server with her money or personal data. <br />
<br />
What happens if Mallory finds Alice's friendly address, and broadcasts her own transaction to base58(ripemd160("alice@example.com") +checksum), with her own public key ? Bob should accept only the first valid transaction, and ignore later ones. This has the disadvantage that if Alice looses her initial keypair, "alice@example.com" is unusable for eternity. A more complex scheme could be devised where updates, revokes and reuse can be enabled.<br />
<br />
What about address colisions ? RIPEMD160 80 bits of collision resistance should offer sufficient protection against accidental collisions; for deliberate collisions, we are exactly in the previous situations and the protocol should prevent it.<br />
<br />
There seem to be at least two similar but-incompatible schemes for doing what I proposed above as the "naive approach". Here I was thinking I am being original :):<br />
* https://en.bitcoin.it/wiki/BIP_0015<br />
* http://ecdsa.org/bitcoin_URIs.html<br />
<br />
Judging by [http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg00419.html|discussion in the mailing list], BIP15 was deferred because it lacked a clear way to authenticate the relay (alias) server. HTTPS is not enough.<br />
The electrum proposal tries to do some authentication, using an undefined "trusted authority". Not very useful.<br />
If we can define a good way to publish Alice's pubkey into the blockchain and use it further to authenticate and encrypt the exchange, we are making progress towards a working protocol. Coin destruction and spamming should be kept to a minimum or zero.<br />
<br />
==UnSpammable Publication of Senders' Public Keys==<br />
<br />
Using the Namecoin block-chain, it is possible for the sender to publish their pubkey for secure communication with their friendly address, without also enabling an attacker to make large numbers of desirable user accounts of domains unavailable by publishing ownership over them without the domain owner's permission in the bitcoin block-chain. The scheme, proposed [https://bitcointalk.org/index.php?topic=74572.msg847022#msg847022 here], would work as follows:<br />
<br />
*A relay server registers example.bit in the namecoin block-chain.<br />
*The relay server creates a base58(ripemd160("example.bit") +checksum)) hash, and sends a namecoin-bitcent/satoshi/etc to it from the namecoin address that example.bit is registered with at the time, thus publishing the pubkey of example.bit, which will be used to verify its signatures<br />
* When Alice is registering alice@example.bit, the relay server creates a digital signature for "alice@example.bit" using the privkey of the example.bit pubkey published in the namecoin block-chain, and sends it to Alice through a secure channel<br />
* Alice creates a bitcoin transaction, sending one bitcent/satoshi/etc to base58(ripemd160(example.bit-signature("alice@example.bit") +checksum)), thus publishing her public key.<br />
* When Bob wants to make a payment to alice@example.bit, he scans the namecoin block-chain for the earliest spend to base58(ripemd160("example.bit") +checksum))<br />
* He checks if the spend came from the namecoin address that example.bit was registered at at the time of the spend, and if it didn't, he looks for the next earliest spend, and does this until he finds a spend to base58(ripemd160("example.bit") +checksum)) that came from example.bit's namecoin address<br />
* Once Bob finds the spend, he considers the pubkey used for the spend as example.bit's official pubkey for signature verification<br />
* Bob asks example.bit for a digital signature of alice@example.bit, and uses example.bit's published pubkey to verify the signature was made by example.bit's official privkey<br />
* Bob scans the bitcoin block-chain for the earliest spend to base58(ripemd160(example.bit-signature("alice@example.bit") +checksum), and obtain's Alice's pubkey<br />
* There is no way the owners of example.bit could have cheated and given Bob a different signature for alice@example.bit than they gave to Alice when she published her pubkey, because every namecoin address can only ever have one official pubkey, that can never be altered</div>Amincdhttps://en.bitcoin.it/w/index.php?title=Friendly_addresses_with_enhanced_privacy&diff=25245Friendly addresses with enhanced privacy2012-04-11T20:23:02Z<p>Amincd: /* UnSpammable Publication of Senders' Public Keys */</p>
<hr />
<div>The 'friendly addresses with enhanced privacy' protocol, [https://bitcointalk.org/index.php?topic=74572.0 proposed] by BubbleBoy, would provide increased privacy and improved usability in bitcoin usage. The proposal in its original form is reproduced here:<br />
<br />
==Proposal==<br />
<br />
It's my opinion that exposing a SHA256 hash to the general public is bad usability. People would much rather publish a friendly address in a format that can easily be dictated over the phone, written down or memorized, similar to the way PayPal/Skrill/Neteller work, where an email address is the identity of the account holder. They would also like to include private payment details with each transaction, such as invoice numbers, and have the option of easily providing a refund when they desire.<br />
<br />
Additionally, publishing a single base58 hash ''reduces privacy'' because it can help trace related payments to that address. A political candidate might not want to disclose the total amount of donations received. As a donor, I wouldn't want my friend and business partners to find out that some of the money they sent me ended up in a well known collection box. Since ECDSA keys are cheap, maximum privacy is achieved when each real world transaction has it's own unique address, and they are not aggregated in a master key, but rather spent individually by the recipient.<br />
<br />
Combining the two requirements, I am proposing a distributed online protocol that resolves friendly names to base58 hashes, ensuring at the same time that each transaction has it's own unique address. The protocol works using a trusted 3rd party that acts as an always-on relay point on behalf of the user, similar to an email server. The payload (money / private keys) is not under the server's control, only the public address list and their mapping to a friendly address. Privacy focused individuals who don't want to disclose even the transaction list to a 3rd party can host their own relay server.<br />
<br />
A conceptual workflow would go something like this:<br />
* Alice creates a large number of private keys and stores them offline, keeping only the public corresponding public addresses; for space concerns the private keys could be generated based on a single seed that is easy to store<br />
* Alice creates an account on the relay server, establishes an authentication token, and assigns herself a friendly address: alice@example.com <br />
* Using her authentication token, Alice's client periodically contacts the relay server and queries for recent activity related to her account ("activity" will be defined bellow); if the base58 address pool is depleted, for example on first connect, the client uploads fresh keys generated in step 1<br />
* Alice publishes her friendly address to friends, family, business partners, Bob and Mallory<br />
* When Bob desires to make a payment to Alice, he enters Alice's friendly address in his client, the amount to send, some description and any other application-specific data<br />
* Bob's client scans it's wallet and discovers it can match Bob's entered amount exactly by spending three private keys it owns<br />
* Bob's client parses the address into a server and user part, contacts the relay server via DNS/HTTP and POSTs a request for a transaction. For example the post address and data could go something like this:<br />
:POST to: https://example.com/relay_server<br />
:URL-encoded data:<br />
:user=alice&currency=BTC&amount=500&want_addr=3&description=Paycheck%20December&payer=bob@example.or:g&meta1=value1&meta2=value2&...<br />
* The relay server extracts three of Alice's base58 hashes from the pool of [i]available hashes[/i], records them in the database of [i]used hashes[/i] along with the information posted by Bob, and returns the addresses to Bob's client<br />
* Bob's client makes transactions as usual to the addresses it obtained, and publishes them in the blockchain<br />
* On the next refresh, Alice's client will contact the server and find what addresses where used, and the associated payer meta information; if the transactions exists in the blockchain, then Alice will be able to see a user friendly entry in her incoming log, that maps all 3 sends to a single entry and shows the associated payer addr and meta information, just like a regular e-wallet<br />
<br />
<br />
For maximum compatibility and easy deployment, the server works on top of DNS and HTTP, but it could be also deployed over Namecoin/Tor. It's also coin agnostic and could be implemented for any other currency besides Bitcoin. If Bob does not want to disclose his IP address to Alice's relay server, he can resolve her friendly name via Tor. It's also optional for Bob to disclose or not his own friendly address under the "payer" POST field.<br />
<br />
The system has the advantage that Mallory cannot find anything by queering the relay server. She will obtain a unique and random string that is never used in the blockchain and reveals no information about Alice. The only way to find out more is to send money to Alice and trance them further. But if Alice employs the same protocol when spending the money received from Mallory, then Mallory cannot find '''anything''' about Alice's other partners. <br />
<br />
The protocol offers the convenience of systems such as PayPal without spamming the blockchain with metadata (payment details); metadata is kept private, known only by the Bob, Alice and the server, and it can also be encrypted to exclude the server. It allows easy refund if the payer chose to disclose a return address; without the payer's friendly address, refunds to a base58 addresses are a bad ideea since there is no guarantee the sender has kept the corresponding private key.<br />
<br />
I'm not necessarily keen to have friendly addresses formatted like an email especially since this address would not have email capabilities; The friendly address syntax is yet to be defined and there are a myriad alternatives: alice$example.com, alice^example.com, btc:example.com~alice etc. I've also skimmed over the low level details for server communication since it's too early to lay down the implementation details. Also, DoS by emptying the pool of available hashes should be prevented.<br />
<br />
<br />
'''Later edit, April 03, 2012:'''<br />
<br />
The naive scheme presented above is very vulnerable to a man-in-the middle attack. Alice must trust the relay server, the DNS system, and the SSL provider of example.com; they could conspire to hand out fake keys that are not owned by Alice, seize all of Alice's funds, and log all payment details. <br />
<br />
But the sender and the recipient already have an unforgeable channel at their disposal: the blockchain. Why not use this channel to establish a trusted public key, thus widely reducing the middle man's (relay server) maneuvering capabilities ?<br />
<br />
It could go something like this:<br />
* Alice wants the friendly name alice@example.com, and the owners of example.com allow her to register it<br />
* Alice hashes the friendly name with RIPEMD160, and constructs a globally unique, unspendable bitcoin address: base58(ripemd160("alice@example.com") +checksum),<br />
* The address is unspendable since it's not a hash of a public key; only Alice and friends know this, and it cannot be detected<br />
* Alice creates a ECDSA keypair, and uses it to sign a transfer of a few bitcents to the unspendable address<br />
* Alice has just published ownership of the "alice@example.com" friendly name, with none of the Bitcoin participants seeing anything other than a regular Bitcoin transaction <br />
* Bob wants to send Alice some coins; he repeats the ripmend160 hashing and gets to the unspendable address<br />
* Bob scans his blockchain for spends to this address; it's expected the blockchain is properly indexed for such scans to be cheap<br />
* He finds the single unspent transaction made by Alice, thus obtains her public key<br />
* He contacts the relay server @example.com, and uses the Alice's ECDSA public key to cut the middle man out of the loop:<br />
* The transaction metadata is passed to the relay server as a binary blob, encrypted for Alices's private key using ECIES<br />
* Each address previously uploaded by Alice to the relay server is signed, so Bob can have full confidence Alice gets the money<br />
<br />
Using this scheme, Alice maintains good privacy (she publishes a hashed version of her address), and does not have to trust the relay server with her money or personal data. <br />
<br />
What happens if Mallory finds Alice's friendly address, and broadcasts her own transaction to base58(ripemd160("alice@example.com") +checksum), with her own public key ? Bob should accept only the first valid transaction, and ignore later ones. This has the disadvantage that if Alice looses her initial keypair, "alice@example.com" is unusable for eternity. A more complex scheme could be devised where updates, revokes and reuse can be enabled.<br />
<br />
What about address colisions ? RIPEMD160 80 bits of collision resistance should offer sufficient protection against accidental collisions; for deliberate collisions, we are exactly in the previous situations and the protocol should prevent it.<br />
<br />
There seem to be at least two similar but-incompatible schemes for doing what I proposed above as the "naive approach". Here I was thinking I am being original :):<br />
* https://en.bitcoin.it/wiki/BIP_0015<br />
* http://ecdsa.org/bitcoin_URIs.html<br />
<br />
Judging by [http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg00419.html|discussion in the mailing list], BIP15 was deferred because it lacked a clear way to authenticate the relay (alias) server. HTTPS is not enough.<br />
The electrum proposal tries to do some authentication, using an undefined "trusted authority". Not very useful.<br />
If we can define a good way to publish Alice's pubkey into the blockchain and use it further to authenticate and encrypt the exchange, we are making progress towards a working protocol. Coin destruction and spamming should be kept to a minimum or zero.<br />
<br />
==UnSpammable Publication of Senders' Public Keys==<br />
<br />
Using the Namecoin block-chain, it is possible for the sender to publish their pubkey for secure communication with their friendly address, without also enabling an attacker to make large numbers of desirable user accounts of domains unavailable by publishing ownership over them without the domain owner's permission in the bitcoin block-chain. The scheme, proposed [https://bitcointalk.org/index.php?topic=74572.msg847022#msg847022 here], would work as follows:<br />
<br />
*A relay server registers example.bit in the namecoin block-chain.<br />
*The relay server creates a base58(ripemd160("example.bit") +checksum)) hash, and sends a namecoin-bitcent/satoshi/etc to it from the namecoin address that example.bit is registered with at the time, thus publishing the pubkey of example.bit, which will be used to verify its signatures<br />
* When Alice is registering alice@example.bit, the relay server creates a digital signature for "alice@example.bit" using the privkey of the example.bit pubkey published in the namecoin block-chain, and sends it to Alice through a secure channel<br />
* Alice creates a bitcoin transaction, sending one bitcent/satoshi/etc to base58(ripemd160(example.bit-signature("alice@example.bit") +checksum)), thus publishing her public key.<br />
* When Bob wants to make a payment to alice@example.bit, he scans the namecoin block-chain for the earliest spend to base58(ripemd160("example.bit") +checksum))<br />
* He checks if the spend came from the namecoin address that example.bit was registered at at the time of the spend, and if it didn't, he looks for the next earliest spend, and does this until he finds a spend to base58(ripemd160("example.bit") +checksum)) that came from example.bit's namecoin address<br />
* Once Bob finds the spend, he considers the pubkey used for the spend as example.bit's official pubkey for signature verification<br />
* Bob asks example.bit for a digital signature of alice@example.bit, and uses example.bit's published pubkey to verify the signature was made by example.bit's official privkey<br />
* Bob scans the bitcoin block-chain for the earliest spend to base58(ripemd160(example.bit-signature("alice@example.bit") +checksum), and obtain's Alice's pubkey<br />
* There is no way for the owners of example.bit could have cheated and given Bob a different signature for alice@example.bit than they gave to Alice when she published her pubkey, because every namecoin address can only ever have one official pubkey, that can never be altered</div>Amincdhttps://en.bitcoin.it/w/index.php?title=Friendly_addresses_with_enhanced_privacy&diff=25244Friendly addresses with enhanced privacy2012-04-11T20:21:34Z<p>Amincd: Created page with "The 'friendly addresses with enhanced privacy' protocol, [https://bitcointalk.org/index.php?topic=74572.0 proposed] by BubbleBoy, would provide increased privacy and improved ..."</p>
<hr />
<div>The 'friendly addresses with enhanced privacy' protocol, [https://bitcointalk.org/index.php?topic=74572.0 proposed] by BubbleBoy, would provide increased privacy and improved usability in bitcoin usage. The proposal in its original form is reproduced here:<br />
<br />
==Proposal==<br />
<br />
It's my opinion that exposing a SHA256 hash to the general public is bad usability. People would much rather publish a friendly address in a format that can easily be dictated over the phone, written down or memorized, similar to the way PayPal/Skrill/Neteller work, where an email address is the identity of the account holder. They would also like to include private payment details with each transaction, such as invoice numbers, and have the option of easily providing a refund when they desire.<br />
<br />
Additionally, publishing a single base58 hash ''reduces privacy'' because it can help trace related payments to that address. A political candidate might not want to disclose the total amount of donations received. As a donor, I wouldn't want my friend and business partners to find out that some of the money they sent me ended up in a well known collection box. Since ECDSA keys are cheap, maximum privacy is achieved when each real world transaction has it's own unique address, and they are not aggregated in a master key, but rather spent individually by the recipient.<br />
<br />
Combining the two requirements, I am proposing a distributed online protocol that resolves friendly names to base58 hashes, ensuring at the same time that each transaction has it's own unique address. The protocol works using a trusted 3rd party that acts as an always-on relay point on behalf of the user, similar to an email server. The payload (money / private keys) is not under the server's control, only the public address list and their mapping to a friendly address. Privacy focused individuals who don't want to disclose even the transaction list to a 3rd party can host their own relay server.<br />
<br />
A conceptual workflow would go something like this:<br />
* Alice creates a large number of private keys and stores them offline, keeping only the public corresponding public addresses; for space concerns the private keys could be generated based on a single seed that is easy to store<br />
* Alice creates an account on the relay server, establishes an authentication token, and assigns herself a friendly address: alice@example.com <br />
* Using her authentication token, Alice's client periodically contacts the relay server and queries for recent activity related to her account ("activity" will be defined bellow); if the base58 address pool is depleted, for example on first connect, the client uploads fresh keys generated in step 1<br />
* Alice publishes her friendly address to friends, family, business partners, Bob and Mallory<br />
* When Bob desires to make a payment to Alice, he enters Alice's friendly address in his client, the amount to send, some description and any other application-specific data<br />
* Bob's client scans it's wallet and discovers it can match Bob's entered amount exactly by spending three private keys it owns<br />
* Bob's client parses the address into a server and user part, contacts the relay server via DNS/HTTP and POSTs a request for a transaction. For example the post address and data could go something like this:<br />
:POST to: https://example.com/relay_server<br />
:URL-encoded data:<br />
:user=alice&currency=BTC&amount=500&want_addr=3&description=Paycheck%20December&payer=bob@example.or:g&meta1=value1&meta2=value2&...<br />
* The relay server extracts three of Alice's base58 hashes from the pool of [i]available hashes[/i], records them in the database of [i]used hashes[/i] along with the information posted by Bob, and returns the addresses to Bob's client<br />
* Bob's client makes transactions as usual to the addresses it obtained, and publishes them in the blockchain<br />
* On the next refresh, Alice's client will contact the server and find what addresses where used, and the associated payer meta information; if the transactions exists in the blockchain, then Alice will be able to see a user friendly entry in her incoming log, that maps all 3 sends to a single entry and shows the associated payer addr and meta information, just like a regular e-wallet<br />
<br />
<br />
For maximum compatibility and easy deployment, the server works on top of DNS and HTTP, but it could be also deployed over Namecoin/Tor. It's also coin agnostic and could be implemented for any other currency besides Bitcoin. If Bob does not want to disclose his IP address to Alice's relay server, he can resolve her friendly name via Tor. It's also optional for Bob to disclose or not his own friendly address under the "payer" POST field.<br />
<br />
The system has the advantage that Mallory cannot find anything by queering the relay server. She will obtain a unique and random string that is never used in the blockchain and reveals no information about Alice. The only way to find out more is to send money to Alice and trance them further. But if Alice employs the same protocol when spending the money received from Mallory, then Mallory cannot find '''anything''' about Alice's other partners. <br />
<br />
The protocol offers the convenience of systems such as PayPal without spamming the blockchain with metadata (payment details); metadata is kept private, known only by the Bob, Alice and the server, and it can also be encrypted to exclude the server. It allows easy refund if the payer chose to disclose a return address; without the payer's friendly address, refunds to a base58 addresses are a bad ideea since there is no guarantee the sender has kept the corresponding private key.<br />
<br />
I'm not necessarily keen to have friendly addresses formatted like an email especially since this address would not have email capabilities; The friendly address syntax is yet to be defined and there are a myriad alternatives: alice$example.com, alice^example.com, btc:example.com~alice etc. I've also skimmed over the low level details for server communication since it's too early to lay down the implementation details. Also, DoS by emptying the pool of available hashes should be prevented.<br />
<br />
<br />
'''Later edit, April 03, 2012:'''<br />
<br />
The naive scheme presented above is very vulnerable to a man-in-the middle attack. Alice must trust the relay server, the DNS system, and the SSL provider of example.com; they could conspire to hand out fake keys that are not owned by Alice, seize all of Alice's funds, and log all payment details. <br />
<br />
But the sender and the recipient already have an unforgeable channel at their disposal: the blockchain. Why not use this channel to establish a trusted public key, thus widely reducing the middle man's (relay server) maneuvering capabilities ?<br />
<br />
It could go something like this:<br />
* Alice wants the friendly name alice@example.com, and the owners of example.com allow her to register it<br />
* Alice hashes the friendly name with RIPEMD160, and constructs a globally unique, unspendable bitcoin address: base58(ripemd160("alice@example.com") +checksum),<br />
* The address is unspendable since it's not a hash of a public key; only Alice and friends know this, and it cannot be detected<br />
* Alice creates a ECDSA keypair, and uses it to sign a transfer of a few bitcents to the unspendable address<br />
* Alice has just published ownership of the "alice@example.com" friendly name, with none of the Bitcoin participants seeing anything other than a regular Bitcoin transaction <br />
* Bob wants to send Alice some coins; he repeats the ripmend160 hashing and gets to the unspendable address<br />
* Bob scans his blockchain for spends to this address; it's expected the blockchain is properly indexed for such scans to be cheap<br />
* He finds the single unspent transaction made by Alice, thus obtains her public key<br />
* He contacts the relay server @example.com, and uses the Alice's ECDSA public key to cut the middle man out of the loop:<br />
* The transaction metadata is passed to the relay server as a binary blob, encrypted for Alices's private key using ECIES<br />
* Each address previously uploaded by Alice to the relay server is signed, so Bob can have full confidence Alice gets the money<br />
<br />
Using this scheme, Alice maintains good privacy (she publishes a hashed version of her address), and does not have to trust the relay server with her money or personal data. <br />
<br />
What happens if Mallory finds Alice's friendly address, and broadcasts her own transaction to base58(ripemd160("alice@example.com") +checksum), with her own public key ? Bob should accept only the first valid transaction, and ignore later ones. This has the disadvantage that if Alice looses her initial keypair, "alice@example.com" is unusable for eternity. A more complex scheme could be devised where updates, revokes and reuse can be enabled.<br />
<br />
What about address colisions ? RIPEMD160 80 bits of collision resistance should offer sufficient protection against accidental collisions; for deliberate collisions, we are exactly in the previous situations and the protocol should prevent it.<br />
<br />
There seem to be at least two similar but-incompatible schemes for doing what I proposed above as the "naive approach". Here I was thinking I am being original :):<br />
* https://en.bitcoin.it/wiki/BIP_0015<br />
* http://ecdsa.org/bitcoin_URIs.html<br />
<br />
Judging by [http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg00419.html|discussion in the mailing list], BIP15 was deferred because it lacked a clear way to authenticate the relay (alias) server. HTTPS is not enough.<br />
The electrum proposal tries to do some authentication, using an undefined "trusted authority". Not very useful.<br />
If we can define a good way to publish Alice's pubkey into the blockchain and use it further to authenticate and encrypt the exchange, we are making progress towards a working protocol. Coin destruction and spamming should be kept to a minimum or zero.<br />
<br />
==UnSpammable Publication of Senders' Public Keys==<br />
<br />
Using the Namecoin block-chain, it is possible for the sender to publish their pubkey for secure communication with their friendly address, without also enabling an attacker to make large numbers of desirable user accounts of domains unavailable by publishing ownership over them without the domain owner's permission in the bitcoin block-chain. The scheme, proposed here, would work as follows:<br />
<br />
*A relay server registers example.bit in the namecoin block-chain.<br />
*The relay server creates a base58(ripemd160("example.bit") +checksum)) hash, and sends a namecoin-bitcent/satoshi/etc to it from the namecoin address that example.bit is registered with at the time, thus publishing the pubkey of example.bit, which will be used to verify its signatures<br />
* When Alice is registering alice@example.bit, the relay server creates a digital signature for "alice@example.bit" using the privkey of the example.bit pubkey published in the namecoin block-chain, and sends it to Alice through a secure channel<br />
* Alice creates a bitcoin transaction, sending one bitcent/satoshi/etc to base58(ripemd160(example.bit-signature("alice@example.bit") +checksum)), thus publishing her public key.<br />
* When Bob wants to make a payment to alice@example.bit, he scans the namecoin block-chain for the earliest spend to base58(ripemd160("example.bit") +checksum))<br />
* He checks if the spend came from the namecoin address that example.bit was registered at at the time of the spend, and if it didn't, he looks for the next earliest spend, and does this until he finds a spend to base58(ripemd160("example.bit") +checksum)) that came from example.bit's namecoin address<br />
* Once Bob finds the spend, he considers the pubkey used for the spend as example.bit's official pubkey for signature verification<br />
* Bob asks example.bit for a digital signature of alice@example.bit, and uses example.bit's published pubkey to verify the signature was made by example.bit's official privkey<br />
* Bob scans the bitcoin block-chain for the earliest spend to base58(ripemd160(example.bit-signature("alice@example.bit") +checksum), and obtain's Alice's pubkey<br />
* There is no way for the owners of example.bit could have cheated and given Bob a different signature for alice@example.bit than they gave to Alice when she published her pubkey, because every namecoin address can only ever have one official pubkey, that can never be altered</div>Amincdhttps://en.bitcoin.it/w/index.php?title=Privacy&diff=25234Privacy2012-04-11T07:43:33Z<p>Amincd: mention on friendly addresses with enhanced privacy protocol</p>
<hr />
<div>While the Bitcoin technology [http://www.bitcointalk.org/index.php?topic=241.0 can support] strong anonymity, the current implementation is usually not very anonymous.<br />
<br />
__TOC__<br />
<br />
The main problem is that every transaction is publicly logged. Anyone can see the flow of Bitcoins from address to address (see first image). Alone, this information can't identify anyone because the addresses are just random numbers. However, if ''any'' of the addresses in a transaction's past or future can be tied to an actual identity, it might be possible to work from that point and figure out who owns all of the other addresses. This identity information might come from network analysis, surveillance, or just Googling the address. The officially-encouraged practice of using a new address for every transaction is designed to make this attack more difficult.<br />
[[File:Unknownaddress.png|thumb|The flow of Bitcoins from address to address is public.]]<br />
<br />
The second image shows a simple example. Someone runs both a money exchanger and a site meant to trap people. When Mr. Doe buys from the exchanger and uses those same coins to buy something from the trap site, the attacker can '''prove''' that these two transactions were made by the same person. The block chain would show:<br />
[[File:knownaddress.png|thumb|Finding an "identity anchor" allows you to ruin the anonymity of the system.]]<br />
* Import coins from address A. Send 100 to B. Authorized by (signature).<br />
* Import coins from address B. Send 100 to C. Authorized by (signature).<br />
You can't change your "sending address"; Mr. Doe ''must'' send coins from the same address that he received them on: address B. The attacker knows for a fact that address B is Mr. Doe because the attacker received $5 from Mr. Doe's Paypal account and then sent 100 BTC to that very same address.<br />
<br />
Another example: someone is scammed and posts the address they were using on the Bitcoin forum. It is possible to see which address they sent coins to. When coins are sent from this (the scammer's) address, the addresses that receive them can also be easily found and posted on the forum. In this way, all of these coins are marked as "dirty", potentially over an infinite number of future transactions. When some smart and honest person notices that his address is now listed, he can reveal who he received those coins from. The Bitcoin community can now break some legs, asking, "Who did you receive these coins from? What did you create this address for?" Eventually the original scammer will be found. Clearly, this becomes more difficult the more addresses that exist between the "target" and the "identity point".<br />
<br />
You might be thinking that this attack is not feasible. But consider this case:<br />
* You live in China and want to buy a "real" newspaper for Bitcoins.<br />
* You join the Bitcoin forum and use your address as a signature. Since you are very helpful, you manage to get 30 BTC after a few months.<br />
* Unfortunately, you choose poorly in who you buy the newspaper from: you've chosen a government agent! Maybe you are under the mistaken impression that Bitcoin is perfectly anonymous.<br />
* The government agent looks at the block chain and Googles (or Baidus) every address in it. He finds your address in your signature on the Bitcoin forum. You've left enough personal information in your posts to be identified, so you are now scheduled to be "reeducated".<br />
<br />
You need to protect yourself from both forward attacks (getting something that identifies you using coins that you got with methods that must remain secret, like the scammer example) and reverse attacks (getting something that must remain secret using coins that identify you, like the newspaper example).<br />
<br />
==Staying Anonymous==<br />
<br />
It is only possible to send bitcoins from the same address with which they have been received. However, if one has bitcoins on several address, one can theoretically choose from which address to send the coins. Choosing personally generated coins or an address that you know doesn't reveal information would protect you. Unfortunately, the default Bitcoin client doesn't support this currently, so you must assume that your entire balance can identify you if any of the addresses can. (Bitcoin sends the smallest coins first, though you shouldn't rely on this.)<br />
<br />
You may consider a bitcoin to be "less-anonymous" when an attacker could feasibly find the true identity of a very recent owner of the bitcoin, perhaps because one of the bitcoin addresses was posted to a website, or because he knows some identifying information through other means. <br />
<br />
If your balance has been contaminated by both anonymous and non-anonymous coins, you may take action to make it "clean". <br />
<br />
Recommended way of anonymizing your balance:<br />
* Send however many coins you want to anonymize to a new [[eWallet]] account as a lump sum. There are other [[eWallet]] services however the more widely used the greater the potential for anonymity. <font color="red">This is not an endorsement of trust in the use of [[eWallet]] services. There are no guarantees that any eWallet service won't one day take all your bitcoins and disappear. Use at your own risk.</font> <br />
<br />
With this method an attacker will have to gain access to the eWallet service's transaction logs to continue to follow you in the transaction history. <br />
<br />
The protection that this method offers is significantly reduced if you are trying to anonymize more than about 10% of the total number of Bitcoins that the eWallet service holds. You'll end up getting your own coins back instead of other users' coins. Withdrawing Bitcoins more slowly and in smaller increments will help reduce this problem. Sending coins to an eWallet service in the largest single transfer possible will also help.<br />
<br />
To further enhance your anonymity, you can:<br />
* Send Bitcoins from one EWallet sevice to another and ''then'' to yourself. Each transfer needs to be painstakingly investigated and many transfers will present insurmountable difficulty.<br />
<br />
Once you have an anonymous balance set up, be sure to keep your anonymous and non-anonymous balances completely separate.<br />
<br />
A future version of the client will have coderr's patch which will allow the sender to specify which coins to use in a transaction<ref>[http://bitcointalk.org/index.php?topic=24784.msg307661#msg307661 Patching The Bitcoin Client To Make It More Anonymous]</ref>.<br />
<br />
In the future, trusted relay servers operating on the [[friendly addresses with enhanced privacy]] protocol could provide bitcoin users strong anonymity with increased convenience, thereby eliminating the need to make a trade-off between privacy and ease of use.<br />
<br />
===Helping other people stay anonymous===<br />
* Set up a real [http://www.bitcointalk.org/index.php?topic=241.0 external mixing service]. Make it like an eWallet service but make sure that a user never withdraws the same coins that are put in. Also delete empty addresses and transaction logs. <br />
* Even if you're not a programmer, you can make a slightly less secure version of an external mixing service (as a Tor hidden service, preferably):<br />
** Set up two Bitcoin installations.<br />
** Put some amount of BTC in installation B. This is the maximum amount of BTC you can deal with at once (for all customers).<br />
** Customers send BTC to installation A. You send them an equal number of coins (or minus a fee) from installation B. Send as 10-50 BTC increments.<br />
** Send all coins from A to B when '''all''' orders are satisfied. You can't send coins from A to B if you have any orders that have not been satisfied from B.<br />
** This can be automated, or you can do everything manually.<br />
* Put lots of Bitcoins in an eWallet service and keep it there. If anyone uses the anonymization method described in "staying anonymous" above, this will enhance it. Send in smaller increments if a large amount is transferred.<br />
<br />
==Legality==<br />
Obviously, using Bitcoin anonymity techniques for the purposes of [[Wikipedia:money laundering|money laundering]] is illegal, but participating or running schemes which others use for money laundering may also be illegal or at least leave the participant vulnerable to accusations of aiding criminals and terrorists. Bitcoin anonymity techniques involving bitcoins worth large amounts of money (over some value between FJ$1,100 and US$58,000, depending on your jurisdiction) is illegal in most jurisdictions, being in violation of [[Wikipedia:Structuring|anti-structuring laws]].<br />
<br />
==See Also==<br />
<br />
* [http://www.bitcoin.org/smf/index.php?topic=2893.0 RFC: Bitcoin Mixnet]<br />
* [http://www.bitcoin.org/smf/index.php?topic=241.0 anonymity]<br />
* [[Bitcoin Fog]]<br />
* [[Bitcoin Laundry]] (Does not mix well -- you may get your own coins back.)<br />
* [http://bitcointalk.org/index.php?topic=24784.0 Patching The Bitcoin Client To Make It More Anonymous]<br />
* [http://arxiv.org/abs/1107.4524 An Analysis of Anonymity in the Bitcoin System] research by Fergal Reid, Martin Harrigan ([http://bitcointalk.org/index.php?topic=31539.0 discussion])<br />
<br />
==References==<br />
<references /><br />
<br />
[[Category:Technical]]</div>Amincdhttps://en.bitcoin.it/w/index.php?title=Green_address&diff=25201Green address2012-04-10T07:02:21Z<p>Amincd: </p>
<hr />
<div>A '''green address''' is a special trusted [[Bitcoin address]] that is used to indicate the origin of funds to a recipient. Assuming the recipient trusts the owner of the address to not attempt a [[double spend]], the recipient may treat the funds as confirmed the moment they arrive.<br />
<br />
As an example, assume website Z accepts incoming Bitcoin payments, but also trusts the green address published by [[Mt. Gox]]. Customer C wants to withdraw funds from Mt. Gox and send them to a payment address of website Z. A customer who does a withdrawal from Mt. Gox can click the ''use green address'' checkbox, which will result in the payment being sent to the green address as an intermediate step before forwarding the payment to site Z. Site Z can confirm that the payment passed through Mt. Gox's green address and trust the payment as confirmed immediately, since it knows that the only party who could potentially perform an attack to reverse the payment is Mt. Gox, which is presumed unlikely.<br />
<br />
The concept originated on the forums and was discussed in two threads<ref>https://bitcointalk.org/index.php?topic=48170</ref><ref>https://bitcointalk.org/index.php?topic=32818.0</ref>. Since then, it has been implemented by [[Instawallet]] and [[Mt. Gox]].<br />
<br />
See Also <ref>http://bitcoin.stackexchange.com/questions/1730/what-are-green-addresses/1731#1731</ref><br />
<br />
==Sites that allow withdrawals from green addresses==<br />
* [https://mtgox.com MtGox ]<br />
<br />
==Sites that recognize green addresses==<br />
* [[Btctip|BTCTip]]<br />
* [[BTCPak]]<br />
<br />
==References==<br />
<br />
<br />
<references/></div>Amincdhttps://en.bitcoin.it/w/index.php?title=Green_address&diff=25187Green address2012-04-09T23:57:32Z<p>Amincd: </p>
<hr />
<div>A '''green address''' is a special trusted [[Bitcoin address]] that is used to indicate the origin of funds to a recipient. Assuming the recipient trusts the owner of the address to not attempt a [[double spend]], the recipient may treat the funds as confirmed the moment they arrive.<br />
<br />
As an example, assume website Z accepts incoming Bitcoin payments, but also trusts the green address published by [[Mt. Gox]]. Customer C wants to withdraw funds from Mt. Gox and send them to a payment address of website Z. A customer who does a withdrawal from Mt. Gox can click the ''use green address'' checkbox, which will result in the payment being sent to the green address as an intermediate step before forwarding the payment to site Z. Site Z can confirm that the payment passed through Mt. Gox's green address and trust the payment as confirmed immediately, since it knows that the only party who could potentially perform an attack to reverse the payment is Mt. Gox, which is presumed unlikely.<br />
<br />
The concept originated on the forums and was discussed in two threads<ref>https://bitcointalk.org/index.php?topic=48170</ref><ref>https://bitcointalk.org/index.php?topic=32818.0</ref>. Since then, it has been implemented by [[Instawallet]] and [[Mt. Gox]].<br />
<br />
See Also <ref>http://bitcoin.stackexchange.com/questions/1730/what-are-green-addresses/1731#1731</ref><br />
<br />
==Sites that allow withdrawals from green addresses==<br />
* [https://mtgox.com MtGox ]<br />
<br />
==Sites that recognize green addresses==<br />
* [[Btctip]]<br />
* [[BTCPak]]<br />
<br />
==References==<br />
<br />
<br />
<references/></div>Amincdhttps://en.bitcoin.it/w/index.php?title=Green_address&diff=24551Green address2012-03-09T03:24:47Z<p>Amincd: </p>
<hr />
<div>A '''green address''' is a special trusted [[Bitcoin address]] that is used to indicate the origin of funds to a recipient. Assuming the recipient trusts the owner of the address to not attempt a [[double spend]], the recipient may treat the funds as confirmed the moment they arrive.<br />
<br />
As an example, assume website Z accepts incoming Bitcoin payments, but also trusts the green address published by [[Mt. Gox]]. Customer C wants to withdraw funds from Mt. Gox and send them to a payment address of website Z. A customer who does a withdrawal from Mt. Gox can click the ''use green address'' checkbox, which will result in the payment being sent to the green address as an intermediate step before forwarding the payment to site Z. Site Z can confirm that the payment passed through Mt. Gox's green address and trust the payment as confirmed immediately, since it knows that the only party who could potentially perform an attack to reverse the payment is Mt. Gox, which is presumed unlikely.<br />
<br />
The concept originated on the forums and was discussed in two threads<ref>https://bitcointalk.org/index.php?topic=48170</ref><ref>https://bitcointalk.org/index.php?topic=32818.0</ref>. Since then, it has been implemented by [[Instawallet]] and [[Mt. Gox]].<br />
<br />
See Also <ref>http://bitcoin.stackexchange.com/questions/1730/what-are-green-addresses/1731#1731</ref><br />
<br />
==Sites that recognize green addresses==<br />
* [https://mtgox.com MtGox ]<br />
* [https://btctip.com Btctip]<br />
* [[BTCPak]]<br />
* [https://www.instawallet.org instawallet]<br />
<br />
==References==<br />
<br />
<br />
<references/></div>Amincdhttps://en.bitcoin.it/w/index.php?title=Ideal_Properties_of_Digital_Commodities&diff=21924Ideal Properties of Digital Commodities2012-01-09T09:28:54Z<p>Amincd: updates in light of developments since 01/2011</p>
<hr />
<div>Inspired by the thread: http://bitcointalk.org/index.php?topic=2966.0<br />
<br />
'''Ideal Properties of Decentralized Digital Commodity'''<br />
<br />
If we had the ability to design and implement an ideal form of digital commodity money, what would it look like? How does Bitcoin currently compare?<br />
<br />
it might seem like some of these things are mutually exclusive, but time and time again humans have made the "impossible" possible, so feel free to think hypothetically here.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Property !! Ideal Implementation !! Bitcoin's Current Rating (A..F) !! Notes<br />
|-<br />
| Decentralized || no single point of failure or issuing authority || A.<br />
|-<br />
| Scarce || required to be a reasonable store of value || A.<br />
|-<br />
| Divisible || should be as close to infinitely divisible as possible || C.<br />
|-<br />
| Storage || actual commodity should be cheap and easy to physically store securely || A.<br />
|-<br />
| Irreversible Transactions || transactions should be irreversible || B. || irreversible after an hour, often not acceptable wait time<br />
|-<br />
| Anonymous || untraceable transactions (if desired) || C. || currently requires some trusted third party to obsfucate transactions<br />
|-<br />
| Unspoofable || should be exceedingly difficult to counterfeit || A.<br />
|-<br />
| Verifiable Funds** || publicly auditable balances, with account holder's permission, to verify funds before making a transaction or make sure that a third party has not moved your funds || C. || since permission is not required<br />
|-<br />
| Gratis Transactions || transactions should be gratis, or nearly so, forever || D || bitcoin future tx fees are certain, but could remain low<br />
|-<br />
| Unique Use-Value? || ideally a commodity should have a unique non-monetary use-value || D || BTC is the only currency that can be used to pay for storing data in the block chain, which is useful for secure timestamping. Competing block chains would probably not have the required incentives for generating that Bitcoin does.<br />
|-<br />
| Offline Transactions || ideally two participants should be able to safely transact without requiring internet access or trust of one another (like normal cash) || C || Bitcoin can be used in off-line transactions using physical representations, like [[Casascius physical bitcoins]] and [[Bitbills]], that give parties an assurance, through producing tamper evidence upon redemption, that the bitcoins they represent have not been spent<br />
|- <br />
|Speed || ideally transactions would be instantaneous || B || For large values, bitcoin is fast enough only for shipments; anything faster than an hour on average requires compromising security. For small transactions, bitcoin can be practically considered instantaneous since the security risks from an unconfirmed transaction are low<br />
|- <br />
|Scalability || usable for every transaction everywhere in the world || A || The existence of lightwieight and offline transactions (e.g. Casascius Coins and Bitbills) can replace the need for conventional cash<br />
|- <br />
|Stability || value in the future is predictable, within reasonable bounds || D || Bitcoin value is highly volatile, with no mechanisms to encourage stability or avoid bubbles. Supply is pre-determined, which eliminates some uncertainty from future value.<br />
|}<br />
\**May not be a necessary property. Thinking it would be cool if a known address could be audited via a tool like blockexplorer.com but if the coins are moved from that address, they are untraceable.<br />
<br />
[[Category:Economics]]</div>Amincdhttps://en.bitcoin.it/w/index.php?title=Donation-accepting_organizations_and_projects&diff=19686Donation-accepting organizations and projects2011-11-20T18:35:22Z<p>Amincd: </p>
<hr />
<div>Here is a list of organizations that accept bitcoin donations.<br />
Only notable donation-accepting sites should be added here.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Organization<br />
! Purpose<br />
! Donation Page<br />
|-<br />
|[http://www.anonyops.com/index.php Anonyops.com]<br />
|Website dedicated to bringing people up to date with Anonymous actions, operations, and interesting news.<br />
|http://anonyops.com/bitcoindonate.php<br />
|-<br />
|[http://www.indiegogo.com/commonsense A Liberty Upgrade for America (IndieGoGo)]<br />
|Join us as we reach 1.6 million Americans with a message of liberty!<br />
|http://www.indiegogo.com/commonsense<br />
|-<br />
|[http://anapnea.org Anapnea]<br />
|An open ethical shell network aiming to create a community with a spirit of productivity, learning and freedom, to give you a breath of fresh air. Operates an open Gentoo Linux shell network that is accessed daily by hundreds of ethical hackers, developers, designers and geeks around the world.<br />
|[https://twitter.com/anapnea/status/78118988848185345 Bitcoin Donation Address]<br />
|-<br />
|[http://www.anonnews.org/ Anonnews.org]<br />
|Open news platform for Anonymous<br />
|http://anonnews.org/bitcoin.html<br />
|-<br />
|[http://awesome.naquadah.org/ awesome]<br />
|Window manager for X11<br />
|http://awesome.naquadah.org/community/<br />
|-<br />
|[http://www.ezyorg.com/ Organizing & Planning Tool]<br />
|Great tool to organize your next party or business meeting<br />
|http://ezyorg.com/<br />
|-|-<br />
|[https://iplayernotifier.appspot.com/ BBC iPlayer Notifier]<br />
|Email and Google Talk notification of new content available on BBC iPlayer<br />
|https://iplayernotifier.appspot.com/<br />
|-<br />
|[http://www.beatingdebt.org/ BeatingDebt.org]<br />
|Teaching debt prevention by placing educational ads, supporting debt prevention groups, and providing online resources.<br />
|http://www.beatingdebt.org/donate.php#BitCoinDonation<br />
|-<br />
|[http://www.bitcharity.org/ BitCharity]<br />
|Use Bitcoins to donate to your favorite charity<br />
|http://www.bitcharity.org<br />
|-<br />
|[http://www.bluetile.org Bluetile]<br />
|Tiling window manager for GNOME<br />
|http://www.bluetile.org/#development<br />
|-<br />
|[http://brmlab.cz/ Brmlab, hackerspace]<br />
|The first hackerspace in the Czech Republic<br />
|http://brmlab.cz/project/bitcoin<br />
|-<br />
|[http://c4ss.org/ Center for a Stateless Society]<br />
|Builds public awareness of, and support for, market anarchism<br />
|http://c4ss.org/support-the-center<br />
|-<br />
|[http://www.cheat-sheets.org/ Cheat-Sheets.org]<br />
|All cheat sheets, round-ups, quick reference cards, quick reference guides and quick reference sheets in one page.<br />
|[http://www.cheat-sheets.org/ cheat-sheets.org]<br />
|-<br />
|[http://www.bitcoinsreview.com Consumer - Merchant Trust Project]<br />
|An initiative to increase trust between Consumer and Bitcoin Merchants. All proceeds go to the websites fund, which pays for various things such as web-hosting and advertisement.<br />
|http://www.bitcoinsreview.com/donate/<br />
|-<br />
|[http://convergence.io Convergence - Moving beyond Certificate Authorities]<br />
|An agile, distributed, and secure strategy for replacing Certificate Authorities.<br />
|http://convergence.io/involved.html<br />
|-<br />
|[http://ccbib.org Creative Commons Bibliothek]<br />
|A Library dedicated to free books. Free meaning either "Creative Commons" or "out of copyright". The source code for all books is online to ease reprinting with any custom layout. Local groups produce paper versions for lending.<br />
|http://ccbib.org/donate/<br />
|-<br />
|[http://www.cryto.net/ Cryto Coding Collective]<br />
|A non-profit collective of independent developers and contributors that strive for real innovation. Unhindered by monetary incentive, arbitrary guidelines or authoritarian coordinators, it allows for an environment where real innovation takes place. Provides infrastructure like a storage grid, IRC network, and hosting.<br />
|http://www.cryto.net/donate/<br />
|-<br />
|[http://www.DecryptedMatrix.com/ Decrypted Matrix ]<br />
|GOALS: Elevate Human Awareness, Expose Greed & Corruption, Learn from [true] History, Distribute Beneficial Knowledge, Advance [suppressed] Technology, Protect Organic Agriculture, Maximize Human Potential, Promote Global Solutions, Re-integrate with Nature, Act with Love in all<br />
|http://www.DecryptedMatrix.com<br />
|-<br />
|[http://www.degenernet.com/ Degenernet Radio]<br />
|Online radio station founded in 2002 dedicated to promoting independent music from all genres. Music available from [http://www.degenernet.com www.degenernet.com]and on the [http://apps.facebook.com/degenernet Degenernet Radio Facebook App].<br />
|http://www.degenernet.com/donate.php<br />
|-<br />
|[https://www.diasporafoundation.org/donate#bitcoin Diaspora Foundation]<br />
|The people behind Diaspora, a distributed "social network". They're also running one public Diaspora server ([http://joindiaspora.com joindiaspora.com]).<br />
|https://www.diasporafoundation.org/donate#bitcoin<br />
|-<br />
|[http://opensource.doppelstern.com Doppelstern Antispam]<br />
|Doppelstern Antispam signatures for ClamAV<br />
|http://opensource.doppelstern.com<br />
|-<br />
|[http://www.dosbox.com/ DOSBox]<br />
|An x86 emulator with DOS<br />
|http://www.dosbox.com/crew.php<br />
|-<br />
|[http://spices.org.my/ Early Intervention Program at SPICES]<br />
|An established non-profit organization providing services to children with learning disabilities since 1997<br />
|http://spices.org.my/be-involved/donations/<br />
|-<br />
|[http://encyclopediadramatica.ch/Main_Page Encyclopedia Dramatica]<br />
|4chan's Wikipedia <br />
|http://encyclopediadramatica.ch/donate.php<br />
|-<br />
|[https://www.erowid.org/ Erowid]<br />
|Online library of information about psychoactive plants and chemicals and other topics on altered states of consciousness such as meditation and lucid dreaming.<br />
|https://www.erowid.org/donations/donations_bitcoin.php<br />
|-<br />
|[http://eudemocracia.org/english.html Eudemocracia] NGO<br />
|Dedicated to the creation of a modern form of government that combines these two concepts: direct democracy and internet.<br />
|http://wiki.eudemocracia.org/en/donaciones<br />
|-<br />
|[http://www.foo.be/forban/ Forban]<br />
|Filesharing protocol for local area networks<br />
|http://www.foo.be/forban/<br />
|-<br />
|[http://420chan.org/ 420chan]<br />
|Imageboard community<br />
|http://420chan.org/donate/<br />
|-<br />
|[http://freedomboxfoundation.org FreedomBox Foundation]<br />
|Non-profit turning small plug computers into personal servers that guard your privacy, anonymity and security.<br />
|https://freedomboxfoundation.org/donate<br />
|-<br />
|[http://www.fsf.org Free Software Foundation]<br />
|Worldwide advocate for software freedom and host organization for the GNU Project.<br />
|https://my.fsf.org/donate/other<br />
|-<br />
|[http://www.freetalklive.com/ Free Talk Live]<br />
|Help spread the message of liberty by donating to a liberty leaning nationally syndicated radio show!<br />
|http://www.freetalklive.com/bitcoin<br />
|-<br />
|[http://freedomainradio.com/ Freedomain Radio]<br />
|Online philosophical conversation about freedom, religion, the state, and the family<br />
|http://board.freedomainradio.com/forums/t/30241.aspx<br />
|-<br />
|[http://www.freehal.org/ FreeHAL]<br />
|a self-learning artificial intelligence available as free software<br />
|http://www.freehal.net/funds/?p=do&l=en<br />
|-<br />
|[http://www.gentlelan.de/ GentleLAN]<br />
|Since many years free private LANs in Bremen / Germany <br />
|http://www.gentlelan.de/?page_id=193<br />
|-<br />
|[http://www.reddit.com/r/hackbloc HackBloc on Reddit]<br />
|Hacktivism, Crypto-anarchy, Darknets.<br />
|http://www.reddit.com/r/hackbloc<br />
|-<br />
|[http://www.heavensentgaming.com Heaven Sent Gaming]<br />
|Heaven Sent Gaming is a new media entertainment group founded by Mario Lucero and Isabel Ruiz, in 2006, as a game development team.<br />
|http://heavensentgaming.com/support-and-donations/<br />
|-<br />
|[http://www.helplinux.ru Help Linux]<br />
|Help Linux is the Russian volunteer project aimed to help people with linux. This projects helps anyone to find a skilled in some questions person and ask for help directly.<br />
|http://helplinux.ourproject.org/wiki/about:start<br />
|-<br />
|[http://i2p2.de/ I2P Anonymous Network]<br />
|Anonymising network similar to tor<br />
|http://www.i2p2.de/donate.html<br />
|-<br />
|[http://www.intercom.gs/ Intercom - Emergency Communications Division]<br />
|We Build Censorship Resistant Phone and Communications Networks<br />
|http://www.intercom.gs/support.html<br />
|-<br />
|[http://www.partito-pirata.it/ Italian Pirate Party]<br />
|Italian Pirate Party - Associazione Partito Pirata Italia<br />
|http://www.partito-pirata.it/magazzino/payBTC.html<br />
|-<br />
|[http://lifeboat.com Lifeboat Foundation]<br />
|The Lifeboat Foundation is a nonprofit nongovernmental organization dedicated to encouraging scientific advancements while helping humanity survive existential risks and possible misuse of increasingly powerful technologies, including genetic engineering, nanotechnology, and robotics/AI, as we move towards the Singularity. (Currently offering to double all Bitcoin donations.)<br />
|https://lifeboat.com/ex/summer.growth<br />
|-<br />
|[http://lorea.org/ Lorea]<br />
|A distributed and federated nodal organization of entities working on integrating and pushing available free and open source technologies and networks, for social networking, social economy and autonomy of the people.<br />
|https://n-1.cc/pg/pages/view/14888/<br />
|-<br />
|[http://biohackers.la/ Los Angeles Biohackers]<br />
|Grass-roots biotechnology lab in downtown Los Angeles<br />
|http://www.socal-diybio.org/Main_Page#Donate<br />
|-<br />
|[http://la.indymedia.org/ Los Angeles Indymedia]<br />
|User-generated left-wing news.<br />
|http://la.indymedia.org/<br />
|-<br />
|[http://love2d.org/ LÖVE]<br />
|An open source 2D game engine.<br />
|http://love2d.org/<br />
|-<br />
|[http://mars.radiome.me M.A.R.S. Radio Modern Alternative Rock Splendor ]<br />
|M.A.R.S Radio is an online radio station playing 24/7/365 commercial free alternative rock at 192 Kbps. M.A.R.S. Radio is pleased to provide listeners FM+ audio quality. M.A.R.S. Radio is the first online music radio station to accept Bitcoin donations.<br />
|http://radiome.me/<br />
|-<br />
|[https://github.com/FellowTraveler/Open-Transactions/ Open Transactions]<br />
|Easy-to-use, Financial Crypto and Digital Cash Library.<br />
|https://github.com/FellowTraveler/Moneychanger<br />
|-<br />
|[http://opengameart.org/ OpenGameArt.org]<br />
|Produces and hosts freely licensed art for use in open source games<br />
|http://opengameart.org/content/donate-bitcoins<br />
|-<br />
|[http://www.openwall.com Openwall Project]<br />
|Development of information security related free software, information security research, publications, and community activities aimed at making existing free software safer to use.<br />
|http://www.openwall.com/donations/<br />
|-<br />
|[https://www.operationanonymous.org/ Operation Anonymous]<br />
|Anonymous Political Group<br />
|http://www.operationanonymous.org/<br />
|-<br />
|[http://www.organicdesign.co.nz OrganicDesign]<br />
|A group developing methods and tools to support open-source bottom-up peer-to-peer governance for the people!<br />
|http://www.organicdesign.co.nz<br />
|-<br />
|[http://www.paniq.cc paniq.cc]<br />
|Music from the other side of the universe<br />
|http://www.paniq.cc<br />
|-<br />
|[http://www.liberallibertario.org Partido Liberal Libertario]<br />
|Libertarian Party of Argentina<br />
|http://www.liberallibertario.org/aportes<br />
|-<br />
|[http://pioneerone.tv/ Pioneer One]<br />
|TV series funded purely through donations<br />
|https://twitter.com/pioneeronetv/status/36119594439544832<br />
|-<br />
|[http://plankhead.com/ Plankhead]<br />
|Free/open source media and arts organization<br />
|http://plankhead.com/donate<br />
|-<br />
|[http://plaztika.com/?lang=en Plaztika]<br />
|Non-profit website (only runs on donations) that supports emerging visual artists. If you're an artist, this could be your website!<br />
|http://plaztika.com/Who-are-we<br />
|-<br />
|[https://privacybox.de/index.en.html PrivacyBox]<br />
|System for anonymous and non-trackable contact forms<br />
|https://privacybox.de/donations.en.html<br />
|-<br />
|[http://prometheusfusionperfection.com/ Prometheus Fusion Perfection]<br />
|Open source nuclear fusion research<br />
|http://prometheusfusionperfection.com/2011/02/04/bitcoin-fundraiser/<br />
|-<br />
|[http://protestbarrick.net/ Protest Barrick]<br />
|A global campaign against the world's largest gold miner<br />
|[https://www.mybitcoin.com/sci/paypage.php?amount=20.00&currency=USD&payee_bcaddr=125Gwb3Mn9KSaCS8QN9LQy5k6RPUHEFruV&payee_name=Protest+Barrick+Fund&note=Donate+NOW+to+end+corporate+impunity+in+gold+mining%21 Donate with Bitcoin]<br />
|-<br />
|[http://queeky.com/ Queeky]<br />
|an online drawing community with special drawing tools and creative users from all around the world<br />
|http://www.queeky.com/content/support-queeky-and-donate<br />
|-<br />
|[http://www.recycles.org/ Recycles.Org]<br />
|Nonprofit Recycling and ReUse Network - Nationwide (USA) technology exchange clearinghouse for nonprofit organizations<br />
|http://www.recycles.org/computer/donation/support/<br />
|-<br />
|[https://ripplepay.com/ Ripple]<br />
|Payment system based on trust networks<br />
|https://ripplepay.com/donate/<br />
|-<br />
| [https://riseup.net/ Riseup]<br />
| Tech collective who aim to [https://help.riseup.net/en/about-us aid in the creation of a free society, (...) engaged in struggles against capitalism and other forms of oppression]<br />
| https://help.riseup.net/en/donate#bitcoin<br />
|-<br />
|[http://rusinfo.cc/ RusInfo]<br />
|Russian info agency<br />
|http://rusinfo.cc/help<br />
|-<br />
|[http://seasteading.org The Seasteading Institute]<br />
|To further the establishment and growth of permanent, autonomous ocean communities, enabling innovation with new political and social systems.<br />
|http://twitter.com/#!/patrissimo/status/76392851558244353<br />
|-<br />
|[http://singinst.org Singularity Institute]<br />
|Artificial Intelligence<br />
|http://singinst.org/donate<br />
|-<br />
|[http://somefunnypranks.com/ SomeFunnyPranks.com]<br />
|Loosen your buckle and have a chuckle.<br />
|http://somefunnypranks.com/<br />
|-<br />
| [http://www.sparkleshare.org/ SparkleShare]<br />
| A Free and Open Source host it yourself replacement for file syncing services like Dropbox. It uses the distributed version control system Git as a backend.<br />
| [http://www.sparkleshare.org/support-us/ Bitcoin Donation Address]<br />
|-<br />
|[http://www.demokracjabezposrednia.pl Stowarzyszenie Więcej Demokracji]<br />
|Stowarzyszenie Więcej Demokracji is an association for direct democracy in Poland. We believe that direct democracy is a hope for every country (not only for corrupt Poland). Please help us and donate.<br />
|http://www.demokracjabezposrednia.pl/donate<br />
|-<br />
|[http://wiki.sugarlabs.org Sugar Labs]<br />
|[http://wiki.sugarlabs.org/go/What_is_Sugar%3F Sugar] is a learning environment that reinvents how computers are used for education.<br />
|http://wiki.sugarlabs.org/go/Donate<br />
|-<br />
|[http://gorod-solnca.org/ Sun City]<br />
|Ukrainian centre for children in difficult circumstances<br />
|http://sms.gorod-solnca.org/<br />
|-<br />
|[http://www.symphonyofscience.com/ Symphony of Science]<br />
|A musical project headed by John Boswell, to deliver scientific knowledge in musical form.<br />
|http://www.symphonyofscience.com/<br />
|-<br />
|[http://tahoe-lafs.org/ Tahoe-LAFS]<br />
|A distributed filesystem with funky redundancy properties<br />
|http://tahoe-lafs.org/trac/tahoe-lafs/wiki/BitCoinPage<br />
|-<br />
|[http://tangorin.com Tangorin Japanese Dictionary]<br />
|Tangorin is a free online Japanese dictionary in development since October 2007 by a former Japanology student. It makes use of files provided mainly by The Electronic Dictionary Research and Development Group established within the Faculty of Information Technology at Monash University, Australia.<br />
|http://tangorin.com/bitcoin<br />
|-<br />
|[http://theexperiments.com The Experiments]<br />
|A rock / punk band who's music is free to download and licensed under the Creative Commons<br />
|[http://theexperiments.com Bitcoin Donation Address]<br />
|-<br />
|[http://theicarusproject.net The Icarus Project]<br />
|A mutual aid/peer support organization dedicated to radical mental health<br />
|[http://theicarusproject.net/about-us/donate-to-the-icarus-project Bitcoin Donation Address]<br />
|-<br />
|[https://freenetproject.org/ The Freenet Project]<br />
|The Free Network<br />
|https://freenetproject.org/donate.html<br />
|-<br />
| [http://ThePythonGameBook.com ThePythonGameBook]<br />
| An free creative-commons / GPL - licensed wikibook to learn open source game programming using the programming language Python.<br />
| [http://thepythongamebook.com/en:help?&#donating_money Bitcoin Donation Address]<br />
|-<br />
|[http://torchat.googlecode.com/ TorChat]<br />
|A serverless encrypted anonymous instant messenger running on top of the Tor network<br />
|http://torchat.googlecode.com/<br />
|-<br />
|[https://www.torservers.net/ Torservers.net]<br />
|Runs [http://www.torproject.org/ Tor] relays and bridges<br />
|https://www.torservers.net/donate.html#anonymous<br />
|-<br />
|[https://vaizard.org/ Vaizard institute]<br />
| Backing people who want to make the world a better place by making their ideas real.<br />
|https://vaizard.org/en/about/contacts/<br />
|-<br />
|-<br />
|[http://wikileaks.org wikileaks]<br />
| Whistleblower website<br />
|http://wikileaks.org/support.html<br />
|-<br />
|[http://wlcentral.org/ WL Central]<br />
|News, analysis and action related to wikileaks the famous website . Media and human rights organization covering Wikileaks news, corruption and human rights.<br />
|http://wlcentral.org/q-a<br />
|-<br />
|[http://tmac.technitium.com/ Technitium]<br />
|Technitium MAC Address Changer is a freeware software. We accept bitcoins as a contribution for the software.<br />
|http://blog.technitium.com/2011/08/accepting-donations-again.html<br />
|-<br />
|[http://www.nycga.net/about/ Occupy Wall Street]<br />
|Occupy Wall Street Support via the New York City General Assembly.<br />
|http://www.nycga.net/how-to-help/<br />
|-<br />
|[http://www.expanton.com]<br />
| Occupy Wall Street Support<br />
|http://www.expanton.com/<br />
|-<br />
|[https://wikispooks.com/wiki/Main_Page Wikispooks]<br />
|An encyclopedia of deep political structures and events<br />
|https://wikispooks.com/wiki/WikiSpooks:Donate<br />
|}<br />
<br />
==See Also==<br />
* [http://witcoin.com/charities Charitable organizations] list on [[witcoin]]<br />
* [http://ecdsa.org/fundraiser Fundraiser widgets]</div>Amincdhttps://en.bitcoin.it/w/index.php?title=Donation-accepting_organizations_and_projects&diff=19685Donation-accepting organizations and projects2011-11-20T18:30:02Z<p>Amincd: </p>
<hr />
<div>Here is a list of organizations that accept bitcoin donations.<br />
Only notable donation-accepting sites should be added here.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Organization<br />
! Purpose<br />
! Donation Page<br />
|-<br />
|[http://www.anonyops.com/index.php Anonyops.com]<br />
|Website dedicated to bringing people up to date with Anonymous actions, operations, and interesting news.<br />
|http://anonyops.com/bitcoindonate.php<br />
|-<br />
|[http://www.indiegogo.com/commonsense A Liberty Upgrade for America (IndieGoGo)]<br />
|Join us as we reach 1.6 million Americans with a message of liberty!<br />
|http://www.indiegogo.com/commonsense<br />
|-<br />
|[http://anapnea.org Anapnea]<br />
|An open ethical shell network aiming to create a community with a spirit of productivity, learning and freedom, to give you a breath of fresh air. Operates an open Gentoo Linux shell network that is accessed daily by hundreds of ethical hackers, developers, designers and geeks around the world.<br />
|[https://twitter.com/anapnea/status/78118988848185345 Bitcoin Donation Address]<br />
|-<br />
|[http://www.anonnews.org/ Anonnews.org]<br />
|Open news platform for Anonymous<br />
|http://anonnews.org/bitcoin.html<br />
|-<br />
|[http://awesome.naquadah.org/ awesome]<br />
|Window manager for X11<br />
|http://awesome.naquadah.org/community/<br />
|-<br />
|[http://www.ezyorg.com/ Organizing & Planning Tool]<br />
|Great tool to organize your next party or business meeting<br />
|http://ezyorg.com/<br />
|-|-<br />
|[https://iplayernotifier.appspot.com/ BBC iPlayer Notifier]<br />
|Email and Google Talk notification of new content available on BBC iPlayer<br />
|https://iplayernotifier.appspot.com/<br />
|-<br />
|[http://www.beatingdebt.org/ BeatingDebt.org]<br />
|Teaching debt prevention by placing educational ads, supporting debt prevention groups, and providing online resources.<br />
|http://www.beatingdebt.org/donate.php#BitCoinDonation<br />
|-<br />
|[http://www.bitcharity.org/ BitCharity]<br />
|Use Bitcoins to donate to your favorite charity<br />
|http://www.bitcharity.org<br />
|-<br />
|[http://www.bluetile.org Bluetile]<br />
|Tiling window manager for GNOME<br />
|http://www.bluetile.org/#development<br />
|-<br />
|[http://brmlab.cz/ Brmlab, hackerspace]<br />
|The first hackerspace in the Czech Republic<br />
|http://brmlab.cz/project/bitcoin<br />
|-<br />
|[http://c4ss.org/ Center for a Stateless Society]<br />
|Builds public awareness of, and support for, market anarchism<br />
|http://c4ss.org/support-the-center<br />
|-<br />
|[http://www.cheat-sheets.org/ Cheat-Sheets.org]<br />
|All cheat sheets, round-ups, quick reference cards, quick reference guides and quick reference sheets in one page.<br />
|[http://www.cheat-sheets.org/ cheat-sheets.org]<br />
|-<br />
|[http://www.bitcoinsreview.com Consumer - Merchant Trust Project]<br />
|An initiative to increase trust between Consumer and Bitcoin Merchants. All proceeds go to the websites fund, which pays for various things such as web-hosting and advertisement.<br />
|http://www.bitcoinsreview.com/donate/<br />
|-<br />
|[http://convergence.io Convergence - Moving beyond Certificate Authorities]<br />
|An agile, distributed, and secure strategy for replacing Certificate Authorities.<br />
|http://convergence.io/involved.html<br />
|-<br />
|[http://ccbib.org Creative Commons Bibliothek]<br />
|A Library dedicated to free books. Free meaning either "Creative Commons" or "out of copyright". The source code for all books is online to ease reprinting with any custom layout. Local groups produce paper versions for lending.<br />
|http://ccbib.org/donate/<br />
|-<br />
|[http://www.cryto.net/ Cryto Coding Collective]<br />
|A non-profit collective of independent developers and contributors that strive for real innovation. Unhindered by monetary incentive, arbitrary guidelines or authoritarian coordinators, it allows for an environment where real innovation takes place. Provides infrastructure like a storage grid, IRC network, and hosting.<br />
|http://www.cryto.net/donate/<br />
|-<br />
|[http://www.DecryptedMatrix.com/ Decrypted Matrix ]<br />
|GOALS: Elevate Human Awareness, Expose Greed & Corruption, Learn from [true] History, Distribute Beneficial Knowledge, Advance [suppressed] Technology, Protect Organic Agriculture, Maximize Human Potential, Promote Global Solutions, Re-integrate with Nature, Act with Love in all<br />
|http://www.DecryptedMatrix.com<br />
|-<br />
|[http://www.degenernet.com/ Degenernet Radio]<br />
|Online radio station founded in 2002 dedicated to promoting independent music from all genres. Music available from [http://www.degenernet.com www.degenernet.com]and on the [http://apps.facebook.com/degenernet Degenernet Radio Facebook App].<br />
|http://www.degenernet.com/donate.php<br />
|-<br />
|[https://www.diasporafoundation.org/donate#bitcoin Diaspora Foundation]<br />
|The people behind Diaspora, a distributed "social network". They're also running one public Diaspora server ([http://joindiaspora.com joindiaspora.com]).<br />
|https://www.diasporafoundation.org/donate#bitcoin<br />
|-<br />
|[http://opensource.doppelstern.com Doppelstern Antispam]<br />
|Doppelstern Antispam signatures for ClamAV<br />
|http://opensource.doppelstern.com<br />
|-<br />
|[http://www.dosbox.com/ DOSBox]<br />
|An x86 emulator with DOS<br />
|http://www.dosbox.com/crew.php<br />
|-<br />
|[http://spices.org.my/ Early Intervention Program at SPICES]<br />
|An established non-profit organization providing services to children with learning disabilities since 1997<br />
|http://spices.org.my/be-involved/donations/<br />
|-<br />
|[http://encyclopediadramatica.ch/Main_Page Encyclopedia Dramatica]<br />
|4chan's Wikipedia <br />
|http://encyclopediadramatica.ch/donate.php<br />
|-<br />
|[https://www.erowid.org/ Erowid]<br />
|Online library of information about psychoactive plants and chemicals and other topics on altered states of consciousness such as meditation and lucid dreaming.<br />
|https://www.erowid.org/donations/donations_bitcoin.php<br />
|-<br />
|[http://eudemocracia.org/english.html Eudemocracia] NGO<br />
|Dedicated to the creation of a modern form of government that combines these two concepts: direct democracy and internet.<br />
|http://wiki.eudemocracia.org/en/donaciones<br />
|-<br />
|[http://www.foo.be/forban/ Forban]<br />
|Filesharing protocol for local area networks<br />
|http://www.foo.be/forban/<br />
|-<br />
|[http://420chan.org/ 420chan]<br />
|Imageboard community<br />
|http://420chan.org/donate/<br />
|-<br />
|[http://freedomboxfoundation.org FreedomBox Foundation]<br />
|Non-profit turning small plug computers into personal servers that guard your privacy, anonymity and security.<br />
|https://freedomboxfoundation.org/donate<br />
|-<br />
|[http://www.fsf.org Free Software Foundation]<br />
|Worldwide advocate for software freedom and host organization for the GNU Project.<br />
|https://my.fsf.org/donate/other<br />
|-<br />
|[http://www.freetalklive.com/ Free Talk Live]<br />
|Help spread the message of liberty by donating to a liberty leaning nationally syndicated radio show!<br />
|http://www.freetalklive.com/bitcoin<br />
|-<br />
|[http://freedomainradio.com/ Freedomain Radio]<br />
|Online philosophical conversation about freedom, religion, the state, and the family<br />
|http://board.freedomainradio.com/forums/t/30241.aspx<br />
|-<br />
|[http://www.freehal.org/ FreeHAL]<br />
|a self-learning artificial intelligence available as free software<br />
|http://www.freehal.net/funds/?p=do&l=en<br />
|-<br />
|[http://www.gentlelan.de/ GentleLAN]<br />
|Since many years free private LANs in Bremen / Germany <br />
|http://www.gentlelan.de/?page_id=193<br />
|-<br />
|[http://www.reddit.com/r/hackbloc HackBloc on Reddit]<br />
|Hacktivism, Crypto-anarchy, Darknets.<br />
|http://www.reddit.com/r/hackbloc<br />
|-<br />
|[http://www.heavensentgaming.com Heaven Sent Gaming]<br />
|Heaven Sent Gaming is a new media entertainment group founded by Mario Lucero and Isabel Ruiz, in 2006, as a game development team.<br />
|http://heavensentgaming.com/support-and-donations/<br />
|-<br />
|[http://www.helplinux.ru Help Linux]<br />
|Help Linux is the Russian volunteer project aimed to help people with linux. This projects helps anyone to find a skilled in some questions person and ask for help directly.<br />
|http://helplinux.ourproject.org/wiki/about:start<br />
|-<br />
|[http://i2p2.de/ I2P Anonymous Network]<br />
|Anonymising network similar to tor<br />
|http://www.i2p2.de/donate.html<br />
|-<br />
|[http://www.intercom.gs/ Intercom - Emergency Communications Division]<br />
|We Build Censorship Resistant Phone and Communications Networks<br />
|http://www.intercom.gs/support.html<br />
|-<br />
|[http://www.partito-pirata.it/ Italian Pirate Party]<br />
|Italian Pirate Party - Associazione Partito Pirata Italia<br />
|http://www.partito-pirata.it/magazzino/payBTC.html<br />
|-<br />
|[http://lifeboat.com Lifeboat Foundation]<br />
|The Lifeboat Foundation is a nonprofit nongovernmental organization dedicated to encouraging scientific advancements while helping humanity survive existential risks and possible misuse of increasingly powerful technologies, including genetic engineering, nanotechnology, and robotics/AI, as we move towards the Singularity. (Currently offering to double all Bitcoin donations.)<br />
|https://lifeboat.com/ex/summer.growth<br />
|-<br />
|[http://linuxoutlaws.com/ Linux Outlaws - we aim to misbehave]<br />
|two pragmatic linux users talk about the latest developments in free and open software and culture <br />
|http://linuxoutlaws.com/<br />
|-<br />
|[http://lorea.org/ Lorea]<br />
|A distributed and federated nodal organization of entities working on integrating and pushing available free and open source technologies and networks, for social networking, social economy and autonomy of the people.<br />
|https://n-1.cc/pg/pages/view/14888/<br />
|-<br />
|[http://biohackers.la/ Los Angeles Biohackers]<br />
|Grass-roots biotechnology lab in downtown Los Angeles<br />
|http://www.socal-diybio.org/Main_Page#Donate<br />
|-<br />
|[http://la.indymedia.org/ Los Angeles Indymedia]<br />
|User-generated left-wing news.<br />
|http://la.indymedia.org/<br />
|-<br />
|[http://love2d.org/ LÖVE]<br />
|An open source 2D game engine.<br />
|http://love2d.org/<br />
|-<br />
|[http://mars.radiome.me M.A.R.S. Radio Modern Alternative Rock Splendor ]<br />
|M.A.R.S Radio is an online radio station playing 24/7/365 commercial free alternative rock at 192 Kbps. M.A.R.S. Radio is pleased to provide listeners FM+ audio quality. M.A.R.S. Radio is the first online music radio station to accept Bitcoin donations.<br />
|http://radiome.me/<br />
|-<br />
|[https://github.com/FellowTraveler/Open-Transactions/ Open Transactions]<br />
|Easy-to-use, Financial Crypto and Digital Cash Library.<br />
|https://github.com/FellowTraveler/Moneychanger<br />
|-<br />
|[http://opengameart.org/ OpenGameArt.org]<br />
|Produces and hosts freely licensed art for use in open source games<br />
|http://opengameart.org/content/donate-bitcoins<br />
|-<br />
|[http://www.openwall.com Openwall Project]<br />
|Development of information security related free software, information security research, publications, and community activities aimed at making existing free software safer to use.<br />
|http://www.openwall.com/donations/<br />
|-<br />
|[https://www.operationanonymous.org/ Operation Anonymous]<br />
|Anonymous Political Group<br />
|http://www.operationanonymous.org/<br />
|-<br />
|[http://www.organicdesign.co.nz OrganicDesign]<br />
|A group developing methods and tools to support open-source bottom-up peer-to-peer governance for the people!<br />
|http://www.organicdesign.co.nz<br />
|-<br />
|[http://www.paniq.cc paniq.cc]<br />
|Music from the other side of the universe<br />
|http://www.paniq.cc<br />
|-<br />
|[http://www.liberallibertario.org Partido Liberal Libertario]<br />
|Libertarian Party of Argentina<br />
|http://www.liberallibertario.org/aportes<br />
|-<br />
|[http://pioneerone.tv/ Pioneer One]<br />
|TV series funded purely through donations<br />
|https://twitter.com/pioneeronetv/status/36119594439544832<br />
|-<br />
|[http://plankhead.com/ Plankhead]<br />
|Free/open source media and arts organization<br />
|http://plankhead.com/donate<br />
|-<br />
|[http://plaztika.com/?lang=en Plaztika]<br />
|Non-profit website (only runs on donations) that supports emerging visual artists. If you're an artist, this could be your website!<br />
|http://plaztika.com/Who-are-we<br />
|-<br />
|[https://privacybox.de/index.en.html PrivacyBox]<br />
|System for anonymous and non-trackable contact forms<br />
|https://privacybox.de/donations.en.html<br />
|-<br />
|[http://prometheusfusionperfection.com/ Prometheus Fusion Perfection]<br />
|Open source nuclear fusion research<br />
|http://prometheusfusionperfection.com/2011/02/04/bitcoin-fundraiser/<br />
|-<br />
|[http://protestbarrick.net/ Protest Barrick]<br />
|A global campaign against the world's largest gold miner<br />
|[https://www.mybitcoin.com/sci/paypage.php?amount=20.00&currency=USD&payee_bcaddr=125Gwb3Mn9KSaCS8QN9LQy5k6RPUHEFruV&payee_name=Protest+Barrick+Fund&note=Donate+NOW+to+end+corporate+impunity+in+gold+mining%21 Donate with Bitcoin]<br />
|-<br />
|[http://queeky.com/ Queeky]<br />
|an online drawing community with special drawing tools and creative users from all around the world<br />
|http://www.queeky.com/content/support-queeky-and-donate<br />
|-<br />
|[http://www.recycles.org/ Recycles.Org]<br />
|Nonprofit Recycling and ReUse Network - Nationwide (USA) technology exchange clearinghouse for nonprofit organizations<br />
|http://www.recycles.org/computer/donation/support/<br />
|-<br />
|[https://ripplepay.com/ Ripple]<br />
|Payment system based on trust networks<br />
|https://ripplepay.com/donate/<br />
|-<br />
| [https://riseup.net/ Riseup]<br />
| Tech collective who aim to [https://help.riseup.net/en/about-us aid in the creation of a free society, (...) engaged in struggles against capitalism and other forms of oppression]<br />
| https://help.riseup.net/en/donate#bitcoin<br />
|-<br />
|[http://rusinfo.cc/ RusInfo]<br />
|Russian info agency<br />
|http://rusinfo.cc/help<br />
|-<br />
|[http://seasteading.org The Seasteading Institute]<br />
|To further the establishment and growth of permanent, autonomous ocean communities, enabling innovation with new political and social systems.<br />
|http://twitter.com/#!/patrissimo/status/76392851558244353<br />
|-<br />
|[http://singinst.org Singularity Institute]<br />
|Artificial Intelligence<br />
|http://singinst.org/donate<br />
|-<br />
|[http://somefunnypranks.com/ SomeFunnyPranks.com]<br />
|Loosen your buckle and have a chuckle.<br />
|http://somefunnypranks.com/<br />
|-<br />
| [http://www.sparkleshare.org/ SparkleShare]<br />
| A Free and Open Source host it yourself replacement for file syncing services like Dropbox. It uses the distributed version control system Git as a backend.<br />
| [http://www.sparkleshare.org/support-us/ Bitcoin Donation Address]<br />
|-<br />
|[http://www.demokracjabezposrednia.pl Stowarzyszenie Więcej Demokracji]<br />
|Stowarzyszenie Więcej Demokracji is an association for direct democracy in Poland. We believe that direct democracy is a hope for every country (not only for corrupt Poland). Please help us and donate.<br />
|http://www.demokracjabezposrednia.pl/donate<br />
|-<br />
|[http://wiki.sugarlabs.org Sugar Labs]<br />
|[http://wiki.sugarlabs.org/go/What_is_Sugar%3F Sugar] is a learning environment that reinvents how computers are used for education.<br />
|http://wiki.sugarlabs.org/go/Donate<br />
|-<br />
|[http://gorod-solnca.org/ Sun City]<br />
|Ukrainian centre for children in difficult circumstances<br />
|http://sms.gorod-solnca.org/<br />
|-<br />
|[http://www.symphonyofscience.com/ Symphony of Science]<br />
|A musical project headed by John Boswell, to deliver scientific knowledge in musical form.<br />
|http://www.symphonyofscience.com/<br />
|-<br />
|[http://tahoe-lafs.org/ Tahoe-LAFS]<br />
|A distributed filesystem with funky redundancy properties<br />
|http://tahoe-lafs.org/trac/tahoe-lafs/wiki/BitCoinPage<br />
|-<br />
|[http://tangorin.com Tangorin Japanese Dictionary]<br />
|Tangorin is a free online Japanese dictionary in development since October 2007 by a former Japanology student. It makes use of files provided mainly by The Electronic Dictionary Research and Development Group established within the Faculty of Information Technology at Monash University, Australia.<br />
|http://tangorin.com/bitcoin<br />
|-<br />
|[http://theexperiments.com The Experiments]<br />
|A rock / punk band who's music is free to download and licensed under the Creative Commons<br />
|[http://theexperiments.com Bitcoin Donation Address]<br />
|-<br />
|[http://theicarusproject.net The Icarus Project]<br />
|A mutual aid/peer support organization dedicated to radical mental health<br />
|[http://theicarusproject.net/about-us/donate-to-the-icarus-project Bitcoin Donation Address]<br />
|-<br />
|[https://freenetproject.org/ The Freenet Project]<br />
|The Free Network<br />
|https://freenetproject.org/donate.html<br />
|-<br />
| [http://ThePythonGameBook.com ThePythonGameBook]<br />
| An free creative-commons / GPL - licensed wikibook to learn open source game programming using the programming language Python.<br />
| [http://thepythongamebook.com/en:help?&#donating_money Bitcoin Donation Address]<br />
|-<br />
|[http://torchat.googlecode.com/ TorChat]<br />
|A serverless encrypted anonymous instant messenger running on top of the Tor network<br />
|http://torchat.googlecode.com/<br />
|-<br />
|[https://www.torservers.net/ Torservers.net]<br />
|Runs [http://www.torproject.org/ Tor] relays and bridges<br />
|https://www.torservers.net/donate.html#anonymous<br />
|-<br />
|[https://vaizard.org/ Vaizard institute]<br />
| Backing people who want to make the world a better place by making their ideas real.<br />
|https://vaizard.org/en/about/contacts/<br />
|-<br />
|-<br />
|[http://wikileaks.org wikileaks]<br />
| Whistleblower website<br />
|http://wikileaks.org/support.html<br />
|-<br />
|[http://wlcentral.org/ WL Central]<br />
|News, analysis and action related to wikileaks the famous website . Media and human rights organization covering Wikileaks news, corruption and human rights.<br />
|http://wlcentral.org/q-a<br />
|-<br />
|[http://tmac.technitium.com/ Technitium]<br />
|Technitium MAC Address Changer is a freeware software. We accept bitcoins as a contribution for the software.<br />
|http://blog.technitium.com/2011/08/accepting-donations-again.html<br />
|-<br />
|[http://www.nycga.net/about/ Occupy Wall Street]<br />
|Occupy Wall Street Support via the New York City General Assembly.<br />
|http://www.nycga.net/how-to-help/<br />
|-<br />
|[http://www.expanton.com]<br />
| Occupy Wall Street Support<br />
|http://www.expanton.com/<br />
|-<br />
|[https://wikispooks.com/wiki/Main_Page Wikispooks]<br />
|An encyclopedia of deep political structures and events<br />
|https://wikispooks.com/wiki/WikiSpooks:Donate<br />
|}<br />
<br />
==See Also==<br />
* [http://witcoin.com/charities Charitable organizations] list on [[witcoin]]<br />
* [http://ecdsa.org/fundraiser Fundraiser widgets]</div>Amincdhttps://en.bitcoin.it/w/index.php?title=Donation-accepting_organizations_and_projects&diff=19684Donation-accepting organizations and projects2011-11-20T18:23:55Z<p>Amincd: </p>
<hr />
<div>Here is a list of organizations that accept bitcoin donations.<br />
Only notable donation-accepting sites should be added here.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Organization<br />
! Purpose<br />
! Donation Page<br />
|-<br />
|[http://www.anonyops.com/index.php Anonyops.com]<br />
|Website dedicated to bringing people up to date with Anonymous actions, operations, and interesting news.<br />
|http://anonyops.com/bitcoindonate.php<br />
|-<br />
|[http://www.indiegogo.com/commonsense A Liberty Upgrade for America (IndieGoGo)]<br />
|Join us as we reach 1.6 million Americans with a message of liberty!<br />
|http://www.indiegogo.com/commonsense<br />
|-<br />
|[http://anapnea.org Anapnea]<br />
|An open ethical shell network aiming to create a community with a spirit of productivity, learning and freedom, to give you a breath of fresh air. Operates an open Gentoo Linux shell network that is accessed daily by hundreds of ethical hackers, developers, designers and geeks around the world.<br />
|[https://twitter.com/anapnea/status/78118988848185345 Bitcoin Donation Address]<br />
|-<br />
|[http://www.anonnews.org/ Anonnews.org]<br />
|Open news platform for Anonymous<br />
|http://anonnews.org/bitcoin.html<br />
|-<br />
|[http://awesome.naquadah.org/ awesome]<br />
|Window manager for X11<br />
|http://awesome.naquadah.org/community/<br />
|-<br />
|[http://www.ezyorg.com/ Organizing & Planning Tool]<br />
|Great tool to organize your next party or business meeting<br />
|http://ezyorg.com/<br />
|-|-<br />
|[https://iplayernotifier.appspot.com/ BBC iPlayer Notifier]<br />
|Email and Google Talk notification of new content available on BBC iPlayer<br />
|https://iplayernotifier.appspot.com/<br />
|-<br />
|[http://www.beatingdebt.org/ BeatingDebt.org]<br />
|Teaching debt prevention by placing educational ads, supporting debt prevention groups, and providing online resources.<br />
|http://www.beatingdebt.org/donate.php#BitCoinDonation<br />
|-<br />
|[http://www.bitcharity.org/ BitCharity]<br />
|Use Bitcoins to donate to your favorite charity<br />
|http://www.bitcharity.org<br />
|-<br />
|[http://www.bluetile.org Bluetile]<br />
|Tiling window manager for GNOME<br />
|http://www.bluetile.org/#development<br />
|-<br />
|[http://brmlab.cz/ Brmlab, hackerspace]<br />
|The first hackerspace in the Czech Republic<br />
|http://brmlab.cz/project/bitcoin<br />
|-<br />
|[http://c4ss.org/ Center for a Stateless Society]<br />
|Builds public awareness of, and support for, market anarchism<br />
|http://c4ss.org/support-the-center<br />
|-<br />
|[http://www.cheat-sheets.org/ Cheat-Sheets.org]<br />
|All cheat sheets, round-ups, quick reference cards, quick reference guides and quick reference sheets in one page.<br />
|[http://www.cheat-sheets.org/ cheat-sheets.org]<br />
|-<br />
|[http://www.bitcoinsreview.com Consumer - Merchant Trust Project]<br />
|An initiative to increase trust between Consumer and Bitcoin Merchants. All proceeds go to the websites fund, which pays for various things such as web-hosting and advertisement.<br />
|http://www.bitcoinsreview.com/donate/<br />
|-<br />
|[http://convergence.io Convergence - Moving beyond Certificate Authorities]<br />
|An agile, distributed, and secure strategy for replacing Certificate Authorities.<br />
|http://convergence.io/involved.html<br />
|-<br />
|[http://ccbib.org Creative Commons Bibliothek]<br />
|A Library dedicated to free books. Free meaning either "Creative Commons" or "out of copyright". The source code for all books is online to ease reprinting with any custom layout. Local groups produce paper versions for lending.<br />
|http://ccbib.org/donate/<br />
|-<br />
|[http://www.cryto.net/ Cryto Coding Collective]<br />
|A non-profit collective of independent developers and contributors that strive for real innovation. Unhindered by monetary incentive, arbitrary guidelines or authoritarian coordinators, it allows for an environment where real innovation takes place. Provides infrastructure like a storage grid, IRC network, and hosting.<br />
|http://www.cryto.net/donate/<br />
|-<br />
|[http://www.DecryptedMatrix.com/ Decrypted Matrix ]<br />
|GOALS: Elevate Human Awareness, Expose Greed & Corruption, Learn from [true] History, Distribute Beneficial Knowledge, Advance [suppressed] Technology, Protect Organic Agriculture, Maximize Human Potential, Promote Global Solutions, Re-integrate with Nature, Act with Love in all<br />
|http://www.DecryptedMatrix.com<br />
|-<br />
|[http://www.degenernet.com/ Degenernet Radio]<br />
|Online radio station founded in 2002 dedicated to promoting independent music from all genres. Music available from [http://www.degenernet.com www.degenernet.com]and on the [http://apps.facebook.com/degenernet Degenernet Radio Facebook App].<br />
|http://www.degenernet.com/donate.php<br />
|-<br />
|[https://www.diasporafoundation.org/donate#bitcoin Diaspora Foundation]<br />
|The people behind Diaspora, a distributed "social network". They're also running one public Diaspora server ([http://joindiaspora.com joindiaspora.com]).<br />
|https://www.diasporafoundation.org/donate#bitcoin<br />
|-<br />
|[http://opensource.doppelstern.com Doppelstern Antispam]<br />
|Doppelstern Antispam signatures for ClamAV<br />
|http://opensource.doppelstern.com<br />
|-<br />
|[http://www.dosbox.com/ DOSBox]<br />
|An x86 emulator with DOS<br />
|http://www.dosbox.com/crew.php<br />
|-<br />
|[http://spices.org.my/ Early Intervention Program at SPICES]<br />
|An established non-profit organization providing services to children with learning disabilities since 1997<br />
|http://spices.org.my/be-involved/donations/<br />
|-<br />
|[http://encyclopediadramatica.ch/Main_Page Encyclopedia Dramatica]<br />
|4chan's Wikipedia <br />
|http://encyclopediadramatica.ch/donate.php<br />
|-<br />
|[https://www.erowid.org/ Erowid]<br />
|Online library of information about psychoactive plants and chemicals and other topics on altered states of consciousness such as meditation and lucid dreaming.<br />
|https://www.erowid.org/donations/donations_bitcoin.php<br />
|-<br />
|[http://eudemocracia.org/english.html Eudemocracia] NGO<br />
|Dedicated to the creation of a modern form of government that combines these two concepts: direct democracy and internet.<br />
|http://wiki.eudemocracia.org/en/donaciones<br />
|-<br />
|[http://www.foo.be/forban/ Forban]<br />
|Filesharing protocol for local area networks<br />
|http://www.foo.be/forban/<br />
|-<br />
|[http://420chan.org/ 420chan]<br />
|Imageboard community<br />
|http://420chan.org/donate/<br />
|-<br />
|[http://freedomboxfoundation.org FreedomBox Foundation]<br />
|Non-profit turning small plug computers into personal servers that guard your privacy, anonymity and security.<br />
|https://freedomboxfoundation.org/donate<br />
|-<br />
|[http://www.fsf.org Free Software Foundation]<br />
|Worldwide advocate for software freedom and host organization for the GNU Project.<br />
|https://my.fsf.org/donate/other<br />
|-<br />
|[http://www.freetalklive.com/ Free Talk Live]<br />
|Help spread the message of liberty by donating to a liberty leaning nationally syndicated radio show!<br />
|http://www.freetalklive.com/bitcoin<br />
|-<br />
|[http://freedomainradio.com/ Freedomain Radio]<br />
|Online philosophical conversation about freedom, religion, the state, and the family<br />
|http://board.freedomainradio.com/forums/t/30241.aspx<br />
|-<br />
|[http://www.freehal.org/ FreeHAL]<br />
|a self-learning artificial intelligence available as free software<br />
|http://www.freehal.net/funds/?p=do&l=en<br />
|-<br />
|[http://www.gentlelan.de/ GentleLAN]<br />
|Since many years free private LANs in Bremen / Germany <br />
|http://www.gentlelan.de/?page_id=193<br />
|-<br />
|[http://www.reddit.com/r/hackbloc HackBloc on Reddit]<br />
|Hacktivism, Crypto-anarchy, Darknets.<br />
|http://www.reddit.com/r/hackbloc<br />
|-<br />
|[http://www.heavensentgaming.com Heaven Sent Gaming]<br />
|Heaven Sent Gaming is a new media entertainment group founded by Mario Lucero and Isabel Ruiz, in 2006, as a game development team.<br />
|http://heavensentgaming.com/support-and-donations/<br />
|-<br />
|[http://www.helplinux.ru Help Linux]<br />
|Help Linux is the Russian volunteer project aimed to help people with linux. This projects helps anyone to find a skilled in some questions person and ask for help directly.<br />
|http://helplinux.ourproject.org/wiki/about:start<br />
|-<br />
|[http://i2p2.de/ I2P Anonymous Network]<br />
|Anonymising network similar to tor<br />
|http://www.i2p2.de/donate.html<br />
|-<br />
|[http://www.infinitypfm.org/ Infinity PFM]<br />
|Free/open source personal finance application with Bitcoin support.<br />
|http://www.infinitypfm.org/#donate<br />
|-<br />
|[http://www.intercom.gs/ Intercom - Emergency Communications Division]<br />
|We Build Censorship Resistant Phone and Communications Networks<br />
|http://www.intercom.gs/support.html<br />
|-<br />
|[http://www.partito-pirata.it/ Italian Pirate Party]<br />
|Italian Pirate Party - Associazione Partito Pirata Italia<br />
|http://www.partito-pirata.it/magazzino/payBTC.html<br />
|-<br />
|[http://lifeboat.com Lifeboat Foundation]<br />
|The Lifeboat Foundation is a nonprofit nongovernmental organization dedicated to encouraging scientific advancements while helping humanity survive existential risks and possible misuse of increasingly powerful technologies, including genetic engineering, nanotechnology, and robotics/AI, as we move towards the Singularity. (Currently offering to double all Bitcoin donations.)<br />
|https://lifeboat.com/ex/summer.growth<br />
|-<br />
|[http://linuxoutlaws.com/ Linux Outlaws - we aim to misbehave]<br />
|two pragmatic linux users talk about the latest developments in free and open software and culture <br />
|http://linuxoutlaws.com/<br />
|-<br />
|[http://lorea.org/ Lorea]<br />
|A distributed and federated nodal organization of entities working on integrating and pushing available free and open source technologies and networks, for social networking, social economy and autonomy of the people.<br />
|https://n-1.cc/pg/pages/view/14888/<br />
|-<br />
|[http://biohackers.la/ Los Angeles Biohackers]<br />
|Grass-roots biotechnology lab in downtown Los Angeles<br />
|http://www.socal-diybio.org/Main_Page#Donate<br />
|-<br />
|[http://la.indymedia.org/ Los Angeles Indymedia]<br />
|User-generated left-wing news.<br />
|http://la.indymedia.org/<br />
|-<br />
|[http://love2d.org/ LÖVE]<br />
|An open source 2D game engine.<br />
|http://love2d.org/<br />
|-<br />
|[http://mars.radiome.me M.A.R.S. Radio Modern Alternative Rock Splendor ]<br />
|M.A.R.S Radio is an online radio station playing 24/7/365 commercial free alternative rock at 192 Kbps. M.A.R.S. Radio is pleased to provide listeners FM+ audio quality. M.A.R.S. Radio is the first online music radio station to accept Bitcoin donations.<br />
|http://radiome.me/<br />
|-<br />
|[https://github.com/FellowTraveler/Open-Transactions/ Open Transactions]<br />
|Easy-to-use, Financial Crypto and Digital Cash Library.<br />
|https://github.com/FellowTraveler/Moneychanger<br />
|-<br />
|[http://opengameart.org/ OpenGameArt.org]<br />
|Produces and hosts freely licensed art for use in open source games<br />
|http://opengameart.org/content/donate-bitcoins<br />
|-<br />
|[http://www.openwall.com Openwall Project]<br />
|Development of information security related free software, information security research, publications, and community activities aimed at making existing free software safer to use.<br />
|http://www.openwall.com/donations/<br />
|-<br />
|[https://www.operationanonymous.org/ Operation Anonymous]<br />
|Anonymous Political Group<br />
|http://www.operationanonymous.org/<br />
|-<br />
|[http://www.organicdesign.co.nz OrganicDesign]<br />
|A group developing methods and tools to support open-source bottom-up peer-to-peer governance for the people!<br />
|http://www.organicdesign.co.nz<br />
|-<br />
|[http://www.paniq.cc paniq.cc]<br />
|Music from the other side of the universe<br />
|http://www.paniq.cc<br />
|-<br />
|[http://www.liberallibertario.org Partido Liberal Libertario]<br />
|Libertarian Party of Argentina<br />
|http://www.liberallibertario.org/aportes<br />
|-<br />
|[http://pioneerone.tv/ Pioneer One]<br />
|TV series funded purely through donations<br />
|https://twitter.com/pioneeronetv/status/36119594439544832<br />
|-<br />
|[http://plankhead.com/ Plankhead]<br />
|Free/open source media and arts organization<br />
|http://plankhead.com/donate<br />
|-<br />
|[http://plaztika.com/?lang=en Plaztika]<br />
|Non-profit website (only runs on donations) that supports emerging visual artists. If you're an artist, this could be your website!<br />
|http://plaztika.com/Who-are-we<br />
|-<br />
|[https://privacybox.de/index.en.html PrivacyBox]<br />
|System for anonymous and non-trackable contact forms<br />
|https://privacybox.de/donations.en.html<br />
|-<br />
|[http://prometheusfusionperfection.com/ Prometheus Fusion Perfection]<br />
|Open source nuclear fusion research<br />
|http://prometheusfusionperfection.com/2011/02/04/bitcoin-fundraiser/<br />
|-<br />
|[http://protestbarrick.net/ Protest Barrick]<br />
|A global campaign against the world's largest gold miner<br />
|[https://www.mybitcoin.com/sci/paypage.php?amount=20.00&currency=USD&payee_bcaddr=125Gwb3Mn9KSaCS8QN9LQy5k6RPUHEFruV&payee_name=Protest+Barrick+Fund&note=Donate+NOW+to+end+corporate+impunity+in+gold+mining%21 Donate with Bitcoin]<br />
|-<br />
|[http://queeky.com/ Queeky]<br />
|an online drawing community with special drawing tools and creative users from all around the world<br />
|http://www.queeky.com/content/support-queeky-and-donate<br />
|-<br />
|[http://www.recycles.org/ Recycles.Org]<br />
|Nonprofit Recycling and ReUse Network - Nationwide (USA) technology exchange clearinghouse for nonprofit organizations<br />
|http://www.recycles.org/computer/donation/support/<br />
|-<br />
|[https://ripplepay.com/ Ripple]<br />
|Payment system based on trust networks<br />
|https://ripplepay.com/donate/<br />
|-<br />
| [https://riseup.net/ Riseup]<br />
| Tech collective who aim to [https://help.riseup.net/en/about-us aid in the creation of a free society, (...) engaged in struggles against capitalism and other forms of oppression]<br />
| https://help.riseup.net/en/donate#bitcoin<br />
|-<br />
|[http://rusinfo.cc/ RusInfo]<br />
|Russian info agency<br />
|http://rusinfo.cc/help<br />
|-<br />
|[http://seasteading.org The Seasteading Institute]<br />
|To further the establishment and growth of permanent, autonomous ocean communities, enabling innovation with new political and social systems.<br />
|http://twitter.com/#!/patrissimo/status/76392851558244353<br />
|-<br />
|[http://singinst.org Singularity Institute]<br />
|Artificial Intelligence<br />
|http://singinst.org/donate<br />
|-<br />
|[http://somefunnypranks.com/ SomeFunnyPranks.com]<br />
|Loosen your buckle and have a chuckle.<br />
|http://somefunnypranks.com/<br />
|-<br />
| [http://www.sparkleshare.org/ SparkleShare]<br />
| A Free and Open Source host it yourself replacement for file syncing services like Dropbox. It uses the distributed version control system Git as a backend.<br />
| [http://www.sparkleshare.org/support-us/ Bitcoin Donation Address]<br />
|-<br />
|[http://www.demokracjabezposrednia.pl Stowarzyszenie Więcej Demokracji]<br />
|Stowarzyszenie Więcej Demokracji is an association for direct democracy in Poland. We believe that direct democracy is a hope for every country (not only for corrupt Poland). Please help us and donate.<br />
|http://www.demokracjabezposrednia.pl/donate<br />
|-<br />
|[http://wiki.sugarlabs.org Sugar Labs]<br />
|[http://wiki.sugarlabs.org/go/What_is_Sugar%3F Sugar] is a learning environment that reinvents how computers are used for education.<br />
|http://wiki.sugarlabs.org/go/Donate<br />
|-<br />
|[http://gorod-solnca.org/ Sun City]<br />
|Ukrainian centre for children in difficult circumstances<br />
|http://sms.gorod-solnca.org/<br />
|-<br />
|[http://www.symphonyofscience.com/ Symphony of Science]<br />
|A musical project headed by John Boswell, to deliver scientific knowledge in musical form.<br />
|http://www.symphonyofscience.com/<br />
|-<br />
|[http://tahoe-lafs.org/ Tahoe-LAFS]<br />
|A distributed filesystem with funky redundancy properties<br />
|http://tahoe-lafs.org/trac/tahoe-lafs/wiki/BitCoinPage<br />
|-<br />
|[http://tangorin.com Tangorin Japanese Dictionary]<br />
|Tangorin is a free online Japanese dictionary in development since October 2007 by a former Japanology student. It makes use of files provided mainly by The Electronic Dictionary Research and Development Group established within the Faculty of Information Technology at Monash University, Australia.<br />
|http://tangorin.com/bitcoin<br />
|-<br />
|[http://theexperiments.com The Experiments]<br />
|A rock / punk band who's music is free to download and licensed under the Creative Commons<br />
|[http://theexperiments.com Bitcoin Donation Address]<br />
|-<br />
|[http://theicarusproject.net The Icarus Project]<br />
|A mutual aid/peer support organization dedicated to radical mental health<br />
|[http://theicarusproject.net/about-us/donate-to-the-icarus-project Bitcoin Donation Address]<br />
|-<br />
|[https://freenetproject.org/ The Freenet Project]<br />
|The Free Network<br />
|https://freenetproject.org/donate.html<br />
|-<br />
| [http://ThePythonGameBook.com ThePythonGameBook]<br />
| An free creative-commons / GPL - licensed wikibook to learn open source game programming using the programming language Python.<br />
| [http://thepythongamebook.com/en:help?&#donating_money Bitcoin Donation Address]<br />
|-<br />
|[http://torchat.googlecode.com/ TorChat]<br />
|A serverless encrypted anonymous instant messenger running on top of the Tor network<br />
|http://torchat.googlecode.com/<br />
|-<br />
|[https://www.torservers.net/ Torservers.net]<br />
|Runs [http://www.torproject.org/ Tor] relays and bridges<br />
|https://www.torservers.net/donate.html#anonymous<br />
|-<br />
|[https://vaizard.org/ Vaizard institute]<br />
| Backing people who want to make the world a better place by making their ideas real.<br />
|https://vaizard.org/en/about/contacts/<br />
|-<br />
|-<br />
|[http://wikileaks.org wikileaks]<br />
| Whistleblower website<br />
|http://wikileaks.org/support.html<br />
|-<br />
|[http://wlcentral.org/ WL Central]<br />
|News, analysis and action related to wikileaks the famous website . Media and human rights organization covering Wikileaks news, corruption and human rights.<br />
|http://wlcentral.org/q-a<br />
|-<br />
|[http://tmac.technitium.com/ Technitium]<br />
|Technitium MAC Address Changer is a freeware software. We accept bitcoins as a contribution for the software.<br />
|http://blog.technitium.com/2011/08/accepting-donations-again.html<br />
|-<br />
|[http://www.nycga.net/about/ Occupy Wall Street]<br />
|Occupy Wall Street Support via the New York City General Assembly.<br />
|http://www.nycga.net/how-to-help/<br />
|-<br />
|[http://www.expanton.com]<br />
| Occupy Wall Street Support<br />
|http://www.expanton.com/<br />
|-<br />
|[https://wikispooks.com/wiki/Main_Page Wikispooks]<br />
|An encyclopedia of deep political structures and events<br />
|https://wikispooks.com/wiki/WikiSpooks:Donate<br />
|}<br />
<br />
==See Also==<br />
* [http://witcoin.com/charities Charitable organizations] list on [[witcoin]]<br />
* [http://ecdsa.org/fundraiser Fundraiser widgets]</div>Amincdhttps://en.bitcoin.it/w/index.php?title=Donation-accepting_organizations_and_projects&diff=19683Donation-accepting organizations and projects2011-11-20T18:20:18Z<p>Amincd: </p>
<hr />
<div>Here is a list of organizations that accept bitcoin donations.<br />
Only notable donation-accepting sites should be added here.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Organization<br />
! Purpose<br />
! Donation Page<br />
|-<br />
|[http://www.anonyops.com/index.php Anonyops.com]<br />
|Website dedicated to bringing people up to date with Anonymous actions, operations, and interesting news.<br />
|http://anonyops.com/bitcoindonate.php<br />
|-<br />
|[http://www.indiegogo.com/commonsense A Liberty Upgrade for America (IndieGoGo)]<br />
|Join us as we reach 1.6 million Americans with a message of liberty!<br />
|http://www.indiegogo.com/commonsense<br />
|-<br />
|[http://anapnea.org Anapnea]<br />
|An open ethical shell network aiming to create a community with a spirit of productivity, learning and freedom, to give you a breath of fresh air. Operates an open Gentoo Linux shell network that is accessed daily by hundreds of ethical hackers, developers, designers and geeks around the world.<br />
|[https://twitter.com/anapnea/status/78118988848185345 Bitcoin Donation Address]<br />
|-<br />
|[http://www.anonnews.org/ Anonnews.org]<br />
|Open news platform for Anonymous<br />
|http://anonnews.org/bitcoin.html<br />
|-<br />
|[http://awesome.naquadah.org/ awesome]<br />
|Window manager for X11<br />
|http://awesome.naquadah.org/community/<br />
|-<br />
|[http://www.ezyorg.com/ Organizing & Planning Tool]<br />
|Great tool to organize your next party or business meeting<br />
|http://ezyorg.com/<br />
|-|-<br />
|[https://iplayernotifier.appspot.com/ BBC iPlayer Notifier]<br />
|Email and Google Talk notification of new content available on BBC iPlayer<br />
|https://iplayernotifier.appspot.com/<br />
|-<br />
|[http://www.beatingdebt.org/ BeatingDebt.org]<br />
|Teaching debt prevention by placing educational ads, supporting debt prevention groups, and providing online resources.<br />
|http://www.beatingdebt.org/donate.php#BitCoinDonation<br />
|-<br />
|[http://www.bitcharity.org/ BitCharity]<br />
|Use Bitcoins to donate to your favorite charity<br />
|http://www.bitcharity.org<br />
|-<br />
|[http://www.bluetile.org Bluetile]<br />
|Tiling window manager for GNOME<br />
|http://www.bluetile.org/#development<br />
|-<br />
|[http://brmlab.cz/ Brmlab, hackerspace]<br />
|The first hackerspace in the Czech Republic<br />
|http://brmlab.cz/project/bitcoin<br />
|-<br />
|[http://c4ss.org/ Center for a Stateless Society]<br />
|Builds public awareness of, and support for, market anarchism<br />
|http://c4ss.org/support-the-center<br />
|-<br />
|[http://www.cheat-sheets.org/ Cheat-Sheets.org]<br />
|All cheat sheets, round-ups, quick reference cards, quick reference guides and quick reference sheets in one page.<br />
|[http://www.cheat-sheets.org/ cheat-sheets.org]<br />
|-<br />
|[http://www.bitcoinsreview.com Consumer - Merchant Trust Project]<br />
|An initiative to increase trust between Consumer and Bitcoin Merchants. All proceeds go to the websites fund, which pays for various things such as web-hosting and advertisement.<br />
|http://www.bitcoinsreview.com/donate/<br />
|-<br />
|[http://convergence.io Convergence - Moving beyond Certificate Authorities]<br />
|An agile, distributed, and secure strategy for replacing Certificate Authorities.<br />
|http://convergence.io/involved.html<br />
|-<br />
|[http://ccbib.org Creative Commons Bibliothek]<br />
|A Library dedicated to free books. Free meaning either "Creative Commons" or "out of copyright". The source code for all books is online to ease reprinting with any custom layout. Local groups produce paper versions for lending.<br />
|http://ccbib.org/donate/<br />
|-<br />
|[http://www.cryto.net/ Cryto Coding Collective]<br />
|A non-profit collective of independent developers and contributors that strive for real innovation. Unhindered by monetary incentive, arbitrary guidelines or authoritarian coordinators, it allows for an environment where real innovation takes place. Provides infrastructure like a storage grid, IRC network, and hosting.<br />
|http://www.cryto.net/donate/<br />
|-<br />
|[http://www.DecryptedMatrix.com/ Decrypted Matrix ]<br />
|GOALS: Elevate Human Awareness, Expose Greed & Corruption, Learn from [true] History, Distribute Beneficial Knowledge, Advance [suppressed] Technology, Protect Organic Agriculture, Maximize Human Potential, Promote Global Solutions, Re-integrate with Nature, Act with Love in all<br />
|http://www.DecryptedMatrix.com<br />
|-<br />
|[http://www.degenernet.com/ Degenernet Radio]<br />
|Online radio station founded in 2002 dedicated to promoting independent music from all genres. Music available from [http://www.degenernet.com www.degenernet.com]and on the [http://apps.facebook.com/degenernet Degenernet Radio Facebook App].<br />
|http://www.degenernet.com/donate.php<br />
|-<br />
|[https://www.diasporafoundation.org/donate#bitcoin Diaspora Foundation]<br />
|The people behind Diaspora, a distributed "social network". They're also running one public Diaspora server ([http://joindiaspora.com joindiaspora.com]).<br />
|https://www.diasporafoundation.org/donate#bitcoin<br />
|-<br />
|[http://opensource.doppelstern.com Doppelstern Antispam]<br />
|Doppelstern Antispam signatures for ClamAV<br />
|http://opensource.doppelstern.com<br />
|-<br />
|[http://www.dosbox.com/ DOSBox]<br />
|An x86 emulator with DOS<br />
|http://www.dosbox.com/crew.php<br />
|-<br />
|[http://spices.org.my/ Early Intervention Program at SPICES]<br />
|An established non-profit organization providing services to children with learning disabilities since 1997<br />
|http://spices.org.my/be-involved/donations/<br />
|-<br />
|[http://encyclopediadramatica.ch/Main_Page Encyclopedia Dramatica]<br />
|4chan's Wikipedia <br />
|http://encyclopediadramatica.ch/donate.php<br />
|-<br />
|[https://www.erowid.org/ Erowid]<br />
|Online library of information about psychoactive plants and chemicals and other topics on altered states of consciousness such as meditation and lucid dreaming.<br />
|https://www.erowid.org/donations/donations_bitcoin.php<br />
|-<br />
|[http://eudemocracia.org/english.html Eudemocracia] NGO<br />
|Dedicated to the creation of a modern form of government that combines these two concepts: direct democracy and internet.<br />
|http://wiki.eudemocracia.org/en/donaciones<br />
|-<br />
|[http://www.foo.be/forban/ Forban]<br />
|Filesharing protocol for local area networks<br />
|http://www.foo.be/forban/<br />
|-<br />
|[http://420chan.org/ 420chan]<br />
|Imageboard community<br />
|http://420chan.org/donate/<br />
|-<br />
|[http://freedomboxfoundation.org FreedomBox Foundation]<br />
|Non-profit turning small plug computers into personal servers that guard your privacy, anonymity and security.<br />
|https://freedomboxfoundation.org/donate<br />
|-<br />
|[http://www.fsf.org Free Software Foundation]<br />
|Worldwide advocate for software freedom and host organization for the GNU Project.<br />
|https://my.fsf.org/donate/other<br />
|-<br />
|[http://www.freetalklive.com/ Free Talk Live]<br />
|Help spread the message of liberty by donating to a liberty leaning nationally syndicated radio show!<br />
|http://www.freetalklive.com/bitcoin<br />
|-<br />
|[http://freedomainradio.com/ Freedomain Radio]<br />
|Online philosophical conversation about freedom, religion, the state, and the family<br />
|http://board.freedomainradio.com/forums/t/30241.aspx<br />
|-<br />
|[http://www.freehal.org/ FreeHAL]<br />
|a self-learning artificial intelligence available as free software<br />
|http://www.freehal.net/funds/?p=do&l=en<br />
|-<br />
|[http://www.gentlelan.de/ GentleLAN]<br />
|Since many years free private LANs in Bremen / Germany <br />
|http://www.gentlelan.de/?page_id=193<br />
|-<br />
|[http://privacyfoundation.de German Privacy Foundation]<br />
|protecting privacy, manufacture and sell the CryptoStick (a smartcard on a usb stick)<br />
|http://www.privacyfoundation.de/verein/spenden/<br />
|-<br />
|[http://www.reddit.com/r/hackbloc HackBloc on Reddit]<br />
|Hacktivism, Crypto-anarchy, Darknets.<br />
|http://www.reddit.com/r/hackbloc<br />
|-<br />
|[http://www.heavensentgaming.com Heaven Sent Gaming]<br />
|Heaven Sent Gaming is a new media entertainment group founded by Mario Lucero and Isabel Ruiz, in 2006, as a game development team.<br />
|http://heavensentgaming.com/support-and-donations/<br />
|-<br />
|[http://www.helplinux.ru Help Linux]<br />
|Help Linux is the Russian volunteer project aimed to help people with linux. This projects helps anyone to find a skilled in some questions person and ask for help directly.<br />
|http://helplinux.ourproject.org/wiki/about:start<br />
|-<br />
|[http://i2p2.de/ I2P Anonymous Network]<br />
|Anonymising network similar to tor<br />
|http://www.i2p2.de/donate.html<br />
|-<br />
|[http://www.infinitypfm.org/ Infinity PFM]<br />
|Free/open source personal finance application with Bitcoin support.<br />
|http://www.infinitypfm.org/#donate<br />
|-<br />
|[http://www.intercom.gs/ Intercom - Emergency Communications Division]<br />
|We Build Censorship Resistant Phone and Communications Networks<br />
|http://www.intercom.gs/support.html<br />
|-<br />
|[http://www.partito-pirata.it/ Italian Pirate Party]<br />
|Italian Pirate Party - Associazione Partito Pirata Italia<br />
|http://www.partito-pirata.it/magazzino/payBTC.html<br />
|-<br />
|[http://lifeboat.com Lifeboat Foundation]<br />
|The Lifeboat Foundation is a nonprofit nongovernmental organization dedicated to encouraging scientific advancements while helping humanity survive existential risks and possible misuse of increasingly powerful technologies, including genetic engineering, nanotechnology, and robotics/AI, as we move towards the Singularity. (Currently offering to double all Bitcoin donations.)<br />
|https://lifeboat.com/ex/summer.growth<br />
|-<br />
|[http://linuxoutlaws.com/ Linux Outlaws - we aim to misbehave]<br />
|two pragmatic linux users talk about the latest developments in free and open software and culture <br />
|http://linuxoutlaws.com/<br />
|-<br />
|[http://lorea.org/ Lorea]<br />
|A distributed and federated nodal organization of entities working on integrating and pushing available free and open source technologies and networks, for social networking, social economy and autonomy of the people.<br />
|https://n-1.cc/pg/pages/view/14888/<br />
|-<br />
|[http://biohackers.la/ Los Angeles Biohackers]<br />
|Grass-roots biotechnology lab in downtown Los Angeles<br />
|http://www.socal-diybio.org/Main_Page#Donate<br />
|-<br />
|[http://la.indymedia.org/ Los Angeles Indymedia]<br />
|User-generated left-wing news.<br />
|http://la.indymedia.org/<br />
|-<br />
|[http://love2d.org/ LÖVE]<br />
|An open source 2D game engine.<br />
|http://love2d.org/<br />
|-<br />
|[http://mars.radiome.me M.A.R.S. Radio Modern Alternative Rock Splendor ]<br />
|M.A.R.S Radio is an online radio station playing 24/7/365 commercial free alternative rock at 192 Kbps. M.A.R.S. Radio is pleased to provide listeners FM+ audio quality. M.A.R.S. Radio is the first online music radio station to accept Bitcoin donations.<br />
|http://radiome.me/<br />
|-<br />
|[https://github.com/FellowTraveler/Open-Transactions/ Open Transactions]<br />
|Easy-to-use, Financial Crypto and Digital Cash Library.<br />
|https://github.com/FellowTraveler/Moneychanger<br />
|-<br />
|[http://opengameart.org/ OpenGameArt.org]<br />
|Produces and hosts freely licensed art for use in open source games<br />
|http://opengameart.org/content/donate-bitcoins<br />
|-<br />
|[http://www.openwall.com Openwall Project]<br />
|Development of information security related free software, information security research, publications, and community activities aimed at making existing free software safer to use.<br />
|http://www.openwall.com/donations/<br />
|-<br />
|[https://www.operationanonymous.org/ Operation Anonymous]<br />
|Anonymous Political Group<br />
|http://www.operationanonymous.org/<br />
|-<br />
|[http://www.organicdesign.co.nz OrganicDesign]<br />
|A group developing methods and tools to support open-source bottom-up peer-to-peer governance for the people!<br />
|http://www.organicdesign.co.nz<br />
|-<br />
|[http://www.paniq.cc paniq.cc]<br />
|Music from the other side of the universe<br />
|http://www.paniq.cc<br />
|-<br />
|[http://www.liberallibertario.org Partido Liberal Libertario]<br />
|Libertarian Party of Argentina<br />
|http://www.liberallibertario.org/aportes<br />
|-<br />
|[http://pioneerone.tv/ Pioneer One]<br />
|TV series funded purely through donations<br />
|https://twitter.com/pioneeronetv/status/36119594439544832<br />
|-<br />
|[http://plankhead.com/ Plankhead]<br />
|Free/open source media and arts organization<br />
|http://plankhead.com/donate<br />
|-<br />
|[http://plaztika.com/?lang=en Plaztika]<br />
|Non-profit website (only runs on donations) that supports emerging visual artists. If you're an artist, this could be your website!<br />
|http://plaztika.com/Who-are-we<br />
|-<br />
|[https://privacybox.de/index.en.html PrivacyBox]<br />
|System for anonymous and non-trackable contact forms<br />
|https://privacybox.de/donations.en.html<br />
|-<br />
|[http://prometheusfusionperfection.com/ Prometheus Fusion Perfection]<br />
|Open source nuclear fusion research<br />
|http://prometheusfusionperfection.com/2011/02/04/bitcoin-fundraiser/<br />
|-<br />
|[http://protestbarrick.net/ Protest Barrick]<br />
|A global campaign against the world's largest gold miner<br />
|[https://www.mybitcoin.com/sci/paypage.php?amount=20.00&currency=USD&payee_bcaddr=125Gwb3Mn9KSaCS8QN9LQy5k6RPUHEFruV&payee_name=Protest+Barrick+Fund&note=Donate+NOW+to+end+corporate+impunity+in+gold+mining%21 Donate with Bitcoin]<br />
|-<br />
|[http://queeky.com/ Queeky]<br />
|an online drawing community with special drawing tools and creative users from all around the world<br />
|http://www.queeky.com/content/support-queeky-and-donate<br />
|-<br />
|[http://www.recycles.org/ Recycles.Org]<br />
|Nonprofit Recycling and ReUse Network - Nationwide (USA) technology exchange clearinghouse for nonprofit organizations<br />
|http://www.recycles.org/computer/donation/support/<br />
|-<br />
|[https://ripplepay.com/ Ripple]<br />
|Payment system based on trust networks<br />
|https://ripplepay.com/donate/<br />
|-<br />
| [https://riseup.net/ Riseup]<br />
| Tech collective who aim to [https://help.riseup.net/en/about-us aid in the creation of a free society, (...) engaged in struggles against capitalism and other forms of oppression]<br />
| https://help.riseup.net/en/donate#bitcoin<br />
|-<br />
|[http://rusinfo.cc/ RusInfo]<br />
|Russian info agency<br />
|http://rusinfo.cc/help<br />
|-<br />
|[http://seasteading.org The Seasteading Institute]<br />
|To further the establishment and growth of permanent, autonomous ocean communities, enabling innovation with new political and social systems.<br />
|http://twitter.com/#!/patrissimo/status/76392851558244353<br />
|-<br />
|[http://singinst.org Singularity Institute]<br />
|Artificial Intelligence<br />
|http://singinst.org/donate<br />
|-<br />
|[http://somefunnypranks.com/ SomeFunnyPranks.com]<br />
|Loosen your buckle and have a chuckle.<br />
|http://somefunnypranks.com/<br />
|-<br />
| [http://www.sparkleshare.org/ SparkleShare]<br />
| A Free and Open Source host it yourself replacement for file syncing services like Dropbox. It uses the distributed version control system Git as a backend.<br />
| [http://www.sparkleshare.org/support-us/ Bitcoin Donation Address]<br />
|-<br />
|[http://www.demokracjabezposrednia.pl Stowarzyszenie Więcej Demokracji]<br />
|Stowarzyszenie Więcej Demokracji is an association for direct democracy in Poland. We believe that direct democracy is a hope for every country (not only for corrupt Poland). Please help us and donate.<br />
|http://www.demokracjabezposrednia.pl/donate<br />
|-<br />
|[http://wiki.sugarlabs.org Sugar Labs]<br />
|[http://wiki.sugarlabs.org/go/What_is_Sugar%3F Sugar] is a learning environment that reinvents how computers are used for education.<br />
|http://wiki.sugarlabs.org/go/Donate<br />
|-<br />
|[http://gorod-solnca.org/ Sun City]<br />
|Ukrainian centre for children in difficult circumstances<br />
|http://sms.gorod-solnca.org/<br />
|-<br />
|[http://www.symphonyofscience.com/ Symphony of Science]<br />
|A musical project headed by John Boswell, to deliver scientific knowledge in musical form.<br />
|http://www.symphonyofscience.com/<br />
|-<br />
|[http://tahoe-lafs.org/ Tahoe-LAFS]<br />
|A distributed filesystem with funky redundancy properties<br />
|http://tahoe-lafs.org/trac/tahoe-lafs/wiki/BitCoinPage<br />
|-<br />
|[http://tangorin.com Tangorin Japanese Dictionary]<br />
|Tangorin is a free online Japanese dictionary in development since October 2007 by a former Japanology student. It makes use of files provided mainly by The Electronic Dictionary Research and Development Group established within the Faculty of Information Technology at Monash University, Australia.<br />
|http://tangorin.com/bitcoin<br />
|-<br />
|[http://theexperiments.com The Experiments]<br />
|A rock / punk band who's music is free to download and licensed under the Creative Commons<br />
|[http://theexperiments.com Bitcoin Donation Address]<br />
|-<br />
|[http://theicarusproject.net The Icarus Project]<br />
|A mutual aid/peer support organization dedicated to radical mental health<br />
|[http://theicarusproject.net/about-us/donate-to-the-icarus-project Bitcoin Donation Address]<br />
|-<br />
|[https://freenetproject.org/ The Freenet Project]<br />
|The Free Network<br />
|https://freenetproject.org/donate.html<br />
|-<br />
| [http://ThePythonGameBook.com ThePythonGameBook]<br />
| An free creative-commons / GPL - licensed wikibook to learn open source game programming using the programming language Python.<br />
| [http://thepythongamebook.com/en:help?&#donating_money Bitcoin Donation Address]<br />
|-<br />
|[http://torchat.googlecode.com/ TorChat]<br />
|A serverless encrypted anonymous instant messenger running on top of the Tor network<br />
|http://torchat.googlecode.com/<br />
|-<br />
|[https://www.torservers.net/ Torservers.net]<br />
|Runs [http://www.torproject.org/ Tor] relays and bridges<br />
|https://www.torservers.net/donate.html#anonymous<br />
|-<br />
|[https://vaizard.org/ Vaizard institute]<br />
| Backing people who want to make the world a better place by making their ideas real.<br />
|https://vaizard.org/en/about/contacts/<br />
|-<br />
|-<br />
|[http://wikileaks.org wikileaks]<br />
| Whistleblower website<br />
|http://wikileaks.org/support.html<br />
|-<br />
|[http://wlcentral.org/ WL Central]<br />
|News, analysis and action related to wikileaks the famous website . Media and human rights organization covering Wikileaks news, corruption and human rights.<br />
|http://wlcentral.org/q-a<br />
|-<br />
|[http://tmac.technitium.com/ Technitium]<br />
|Technitium MAC Address Changer is a freeware software. We accept bitcoins as a contribution for the software.<br />
|http://blog.technitium.com/2011/08/accepting-donations-again.html<br />
|-<br />
|[http://www.nycga.net/about/ Occupy Wall Street]<br />
|Occupy Wall Street Support via the New York City General Assembly.<br />
|http://www.nycga.net/how-to-help/<br />
|-<br />
|[http://www.expanton.com]<br />
| Occupy Wall Street Support<br />
|http://www.expanton.com/<br />
|-<br />
|[https://wikispooks.com/wiki/Main_Page Wikispooks]<br />
|An encyclopedia of deep political structures and events<br />
|https://wikispooks.com/wiki/WikiSpooks:Donate<br />
|}<br />
<br />
==See Also==<br />
* [http://witcoin.com/charities Charitable organizations] list on [[witcoin]]<br />
* [http://ecdsa.org/fundraiser Fundraiser widgets]</div>Amincdhttps://en.bitcoin.it/w/index.php?title=StrongCoin&diff=18678StrongCoin2011-10-31T12:37:29Z<p>Amincd: it appears to now have SSL</p>
<hr />
<div>This is a browser-wallet where the key-information is stored in the browser and can be accessed via JavaScript.<br />
<br />
StrongCoin accounts are protected by a passphrase that is known only to the user and only an encrypted key for that password is stored with StrongCoin<ref>[http://bitcointalk.org/index.php?topic=36169.msg445905#msg445905 The Kindle, Bitcoin and client side address generation. (StrongCoin)]</ref>. As such, if the passphrase is forgotten or lost, not even StrongCoin can help to recover the funds. The service does provide the ability to print paper backups of the keys which can be re-imported and when doing so no passphrase is required.<br />
<br />
==Interesting Features==<br />
<br />
*Import of private-keys in [[Mini private key format]]<br />
*Printable "paper" backup of key-pairs<br />
<br />
==Fees==<br />
<br />
* StrongCoin adds 0.01 BTC per spend transaction.<br />
<br />
==External Links==<br />
<br />
* [http://strongcoin.com StrongCoin] website<br />
<br />
==References==<br />
<br />
<references /><br />
<br />
[[Category:EWallets]]</div>Amincdhttps://en.bitcoin.it/w/index.php?title=Testnet&diff=18427Testnet2011-10-23T13:50:36Z<p>Amincd: </p>
<hr />
<div>The '''testnet''' is an alternative Bitcoin [[block chain]], to be used for testing. This allows application developers or bitcoin testers to experiment, without having to use real bitcoins or worrying about breaking the main bitcoin chain.<br />
<br />
Run bitcoin or bitcoind with the -testnet flag to use the testnet (or put testnet=1 in the bitcoin.conf file).<br />
<br />
==Differences==<br />
* Instead of port 8333 (listen), port 18333 is used.<br />
* Bootstrapping IRC channel is #bitcoinTEST instead of #bitcoin (both on irc.lfnet.org). The built-in node list is disabled.<br />
* A different value of ADDRESSVERSION field ensures no testnet BitCoin addresses will work on the production network. (0x6F rather than 0x00)<br />
* The protocol message header bytes are shifted up (0xFABFB5DA instead of 0xF9BEB4D9)<br />
* Minimum [[difficulty]] of 1.0 on testnet is equal to difficulty of 0.5 on mainnet. This means that the mainnet-equivalent of any testnet difficulty is half the testnet difficulty.<br />
* A new genesis block<br />
<br />
==Genesis Block==<br />
<br />
Testnet uses a different genesis block to the main network. You can find it at http://blockexplorer.com/testnet/b/0<br />
The testnet was reset with a new genesis block for the 0.3.20 bitcoin release.<br />
<br />
==External links==<br />
* [https://sourceforge.net/projects/bitcoin/files/Bitcoin/testnet-in-a-box/ Testnet-In-A-Box self-contained testnet]<br />
* [https://bitcointalk.org/?topic=4483.0 Test Network forum topic]<br />
* [https://freebitcoins.appspot.com/test/ Testnet Faucet]<br />
* [http://blockexplorer.com/testnet Testnet Block Explorer]<br />
* [http://blockexplorer.com/testnet/q/getdifficulty Testnet current difficulty] As output by BitCoin's getDifficulty]<br />
<br />
[[Category:Technical]]<br />
[[Category:Developer]]</div>Amincdhttps://en.bitcoin.it/w/index.php?title=Intersango&diff=18426Intersango2011-10-23T13:15:22Z<p>Amincd: /* History */</p>
<hr />
<div>A [[currency exchange|exchange]] offering multiple trading markets for trading bitcoins against multiple currencies.<br />
<br />
Traders add funds and then place orders to buy and sell. Intersango acts as an escrow. The site charges no trading fees.<br />
<br />
[[Bitcoin Consultancy]] operates the exchange.<br />
<br />
Intersango has a trading [https://bitcoinconsultancy.com/wiki/index.php/Intersango/API API]<br />
<br />
==Trading==<br />
===Buying===<br />
<br />
A buy order is executed partially or in full when the price bid can be matched against a sell order that is at or below the bid amount.<br />
<br />
===Selling===<br />
<br />
A sell order is executed partially or in full when the price asked can be matched against a buy order that is at or above the ask amount.<br />
<br />
<br />
No Fee (for a limited time).<br />
<br />
==Adding Funds==<br />
===BTC===<br />
<br />
There are no fees incurred when when transferring bitcoins for deposit. Funds are available once [[confirmation|confirmed]] (4 confirms), a process that can take roughly forty minutes.<br />
<br />
===EUR===<br />
The exchange accepts SEPA bank transfers for deposit. A 5 PLN fee is taken by the bank. No additional fees is taken.<br />
<br />
===PLN===<br />
The exchange accepts polish bank transfers for deposit. There are no fees.<br />
<br />
===USD===<br />
The exchange accepts [[Dwolla]] transfers (no fee), bank wire transfers and ACH. There are no fees.<br />
<br />
===GBP===<br />
The exchange accepts standard UK GBP bank transfers.<br />
<br />
==Withdrawing Funds==<br />
<br />
===BTC===<br />
Bitcoins may be withdrawn at no charge.<br />
<br />
===EUR===<br />
Withdrawals as SEPA transfers. A fee of 5 PLN is taken by the bank. No additional fee is charged.<br />
<br />
===PLN===<br />
Withdrawals as standard polish PLN bank transfers.<br />
<br />
===USD===<br />
Withdrawals are through [[Dwolla]]. There is no fee incurred from the exchange for withdrawing funds.<br />
<br />
===GBP===<br />
Withdrawals as standard UK GBP bank transfers.<br />
<br />
==API==<br />
<br />
See the [https://bitcoinconsultancy.com/wiki/index.php/Intersango/API API page] for more info.<br />
<br />
<source lang="python"><br />
import httplib<br />
import urllib<br />
import json<br />
<br />
class Intersango:<br />
ORDER_QUEUED = 'queued'<br />
ORDER_OPEN = 'open'<br />
ORDER_EXPIRED = 'expired'<br />
ORDER_CANCELLED = 'cancelled'<br />
ORDER_FULFILLED = 'fulfilled'<br />
<br />
BUY = 'false'<br />
SELL = 'true'<br />
<br />
def __init__(self, api_key):<br />
self.connection = httplib.HTTPSConnection('intersango.com')<br />
self.api_key = api_key<br />
<br />
def make_request(self, page, params={}):<br />
headers = {"Content-type": "application/x-www-form-urlencoded",<br />
"Connection": "Keep-Alive", "Keep-Alive": 30,<br />
"Accept": "text/plain"}<br />
if type(params) == dict:<br />
params['api_key'] = self.api_key<br />
elif type(params) == list:<br />
params.append(('api_key', self.api_key))<br />
else:<br />
raise TypeError('Unknown parameter list type')<br />
params = urllib.urlencode(params)<br />
base_url = '/api/authenticated/v0.1/%s.php'%page<br />
self.connection.request('POST', base_url, params, headers)<br />
response = self.connection.getresponse()<br />
if response.status == 404:<br />
return None<br />
return json.loads(response.read())<br />
<br />
def accounts(self):<br />
return self.make_request('listAccounts')<br />
<br />
def orders(self, account_id, states=[], last_order_id=None):<br />
params = [('account_id', account_id)]<br />
for state in states:<br />
params.append(('states[]', state))<br />
if last_order_id is not None:<br />
params.append(('last_order_id', last_order_id))<br />
return self.make_request('listOrders', params)<br />
<br />
def deposits(self, account_id):<br />
return self.make_request('listDeposits', {'account_id': account_id})<br />
<br />
def withdrawals(self, account_id):<br />
return self.make_request('listWithdrawalRequests',<br />
{'account_id': account_id})<br />
<br />
def place_limit_order(self, quantity, rate, is_selling, base_id, quote_id):<br />
params = {'quantity': quantity, 'rate': rate, 'selling': is_selling,<br />
'base_account_id': base_id, 'quote_account_id': quote_id}<br />
return self.make_request('placeLimitOrder', params)<br />
<br />
def cancel_order(self, account_id, order_id):<br />
params = {'account_id': account_id, 'order_id': order_id}<br />
return self.make_request('requestCancelOrder', params)<br />
<br />
def cancel_withdrawal(self, account_id, withdrawal_request_id):<br />
params = {'account_id': account_id, <br />
'withdrawal_request_id': withdrawal_request_id}<br />
return self.make_request('cancelWithdrawalRequest', params)<br />
</source><br />
<br />
Example usage:<br />
<br />
<source lang="python"><br />
intersango = Intersango('3223kdkk323h32kj3hkj23233j')<br />
print 'Accounts: ', intersango.accounts()<br />
print 'Orders: ', \<br />
intersango.orders(411289412410, <br />
[Intersango.ORDER_CANCELLED, Intersango.ORDER_FULFILLED])<br />
print 'Deposits: ', intersango.deposits(861502532543)<br />
print 'Withdrawals: ', intersango.withdrawals(702703681384)<br />
intersango.place_limit_order('1', '2.0', Intersango.BUY, <br />
861502521543, 411982412410)<br />
intersango.cancel_order(412989412410, 21724)<br />
</source><br />
<br />
==History==<br />
<br />
The service was launched on July 6, 2011<ref>[http://forum.bitcoin.org/index.php?topic=26543.0 Intersango.com EUR exchange is now live]</ref>. The Intersango [[:Category:Open Source|open source]] software that the exchange runs on was announced on March 17, 2011<ref>[https://bitcointalk.org/index.php?topic=4579.0 Free Bitcoin exchange software- Intersango]</ref>. In September, 2011 the exchange began using a new version of the Intersango open source exchange project with two currency markets (BTC/EUR, BTC/USD) live under the Intersango brand and plans made for the third (BTC/GBP) when [[Britcoin]] accounts are migrated at a future date.<br />
<br />
==See Also==<br />
<br />
* [[Buying bitcoins]]<br />
* [[Selling bitcoins]]<br />
<br />
==External Links==<br />
<br />
* [https://intersango.com Intersango] EUR exchange website<br />
* [http://gitorious.org/intersango Intersango] exchange project on Gitorious<br />
<br />
==References==<br />
<references/><br />
<br />
[[Category:Exchanges]]<br />
[[Category:eWallets]]</div>Amincdhttps://en.bitcoin.it/w/index.php?title=Intersango&diff=18425Intersango2011-10-23T13:08:14Z<p>Amincd: </p>
<hr />
<div>A [[currency exchange|exchange]] offering multiple trading markets for trading bitcoins against multiple currencies.<br />
<br />
Traders add funds and then place orders to buy and sell. Intersango acts as an escrow. The site charges no trading fees.<br />
<br />
[[Bitcoin Consultancy]] operates the exchange.<br />
<br />
Intersango has a trading [https://bitcoinconsultancy.com/wiki/index.php/Intersango/API API]<br />
<br />
==Trading==<br />
===Buying===<br />
<br />
A buy order is executed partially or in full when the price bid can be matched against a sell order that is at or below the bid amount.<br />
<br />
===Selling===<br />
<br />
A sell order is executed partially or in full when the price asked can be matched against a buy order that is at or above the ask amount.<br />
<br />
<br />
No Fee (for a limited time).<br />
<br />
==Adding Funds==<br />
===BTC===<br />
<br />
There are no fees incurred when when transferring bitcoins for deposit. Funds are available once [[confirmation|confirmed]] (4 confirms), a process that can take roughly forty minutes.<br />
<br />
===EUR===<br />
The exchange accepts SEPA bank transfers for deposit. A 5 PLN fee is taken by the bank. No additional fees is taken.<br />
<br />
===PLN===<br />
The exchange accepts polish bank transfers for deposit. There are no fees.<br />
<br />
===USD===<br />
The exchange accepts [[Dwolla]] transfers (no fee), bank wire transfers and ACH. There are no fees.<br />
<br />
===GBP===<br />
The exchange accepts standard UK GBP bank transfers.<br />
<br />
==Withdrawing Funds==<br />
<br />
===BTC===<br />
Bitcoins may be withdrawn at no charge.<br />
<br />
===EUR===<br />
Withdrawals as SEPA transfers. A fee of 5 PLN is taken by the bank. No additional fee is charged.<br />
<br />
===PLN===<br />
Withdrawals as standard polish PLN bank transfers.<br />
<br />
===USD===<br />
Withdrawals are through [[Dwolla]]. There is no fee incurred from the exchange for withdrawing funds.<br />
<br />
===GBP===<br />
Withdrawals as standard UK GBP bank transfers.<br />
<br />
==API==<br />
<br />
See the [https://bitcoinconsultancy.com/wiki/index.php/Intersango/API API page] for more info.<br />
<br />
<source lang="python"><br />
import httplib<br />
import urllib<br />
import json<br />
<br />
class Intersango:<br />
ORDER_QUEUED = 'queued'<br />
ORDER_OPEN = 'open'<br />
ORDER_EXPIRED = 'expired'<br />
ORDER_CANCELLED = 'cancelled'<br />
ORDER_FULFILLED = 'fulfilled'<br />
<br />
BUY = 'false'<br />
SELL = 'true'<br />
<br />
def __init__(self, api_key):<br />
self.connection = httplib.HTTPSConnection('intersango.com')<br />
self.api_key = api_key<br />
<br />
def make_request(self, page, params={}):<br />
headers = {"Content-type": "application/x-www-form-urlencoded",<br />
"Connection": "Keep-Alive", "Keep-Alive": 30,<br />
"Accept": "text/plain"}<br />
if type(params) == dict:<br />
params['api_key'] = self.api_key<br />
elif type(params) == list:<br />
params.append(('api_key', self.api_key))<br />
else:<br />
raise TypeError('Unknown parameter list type')<br />
params = urllib.urlencode(params)<br />
base_url = '/api/authenticated/v0.1/%s.php'%page<br />
self.connection.request('POST', base_url, params, headers)<br />
response = self.connection.getresponse()<br />
if response.status == 404:<br />
return None<br />
return json.loads(response.read())<br />
<br />
def accounts(self):<br />
return self.make_request('listAccounts')<br />
<br />
def orders(self, account_id, states=[], last_order_id=None):<br />
params = [('account_id', account_id)]<br />
for state in states:<br />
params.append(('states[]', state))<br />
if last_order_id is not None:<br />
params.append(('last_order_id', last_order_id))<br />
return self.make_request('listOrders', params)<br />
<br />
def deposits(self, account_id):<br />
return self.make_request('listDeposits', {'account_id': account_id})<br />
<br />
def withdrawals(self, account_id):<br />
return self.make_request('listWithdrawalRequests',<br />
{'account_id': account_id})<br />
<br />
def place_limit_order(self, quantity, rate, is_selling, base_id, quote_id):<br />
params = {'quantity': quantity, 'rate': rate, 'selling': is_selling,<br />
'base_account_id': base_id, 'quote_account_id': quote_id}<br />
return self.make_request('placeLimitOrder', params)<br />
<br />
def cancel_order(self, account_id, order_id):<br />
params = {'account_id': account_id, 'order_id': order_id}<br />
return self.make_request('requestCancelOrder', params)<br />
<br />
def cancel_withdrawal(self, account_id, withdrawal_request_id):<br />
params = {'account_id': account_id, <br />
'withdrawal_request_id': withdrawal_request_id}<br />
return self.make_request('cancelWithdrawalRequest', params)<br />
</source><br />
<br />
Example usage:<br />
<br />
<source lang="python"><br />
intersango = Intersango('3223kdkk323h32kj3hkj23233j')<br />
print 'Accounts: ', intersango.accounts()<br />
print 'Orders: ', \<br />
intersango.orders(411289412410, <br />
[Intersango.ORDER_CANCELLED, Intersango.ORDER_FULFILLED])<br />
print 'Deposits: ', intersango.deposits(861502532543)<br />
print 'Withdrawals: ', intersango.withdrawals(702703681384)<br />
intersango.place_limit_order('1', '2.0', Intersango.BUY, <br />
861502521543, 411982412410)<br />
intersango.cancel_order(412989412410, 21724)<br />
</source><br />
<br />
==History==<br />
<br />
The service was launched on July 6, 2011<ref>[http://forum.bitcoin.org/index.php?topic=26543.0 Intersango.com EUR exchange is now live]</ref>. The Intersango [[:Category:Open Source|open source]] software that the exchange runs on was announced on March 17, 2011<ref>[http://www.bitcoin.org/smf/index.php?topic=4579.0 Free Bitcoin exchange software- Intersango]</ref>. In September, 2011 the exchange began using a new version of the Intersango open source exchange project with two currency markets (BTC/EUR, BTC/USD) live under the Intersango brand and plans made for the third (BTC/GBP) when [[Britcoin]] accounts are migrated at a future date.<br />
<br />
==See Also==<br />
<br />
* [[Buying bitcoins]]<br />
* [[Selling bitcoins]]<br />
<br />
==External Links==<br />
<br />
* [https://intersango.com Intersango] EUR exchange website<br />
* [http://gitorious.org/intersango Intersango] exchange project on Gitorious<br />
<br />
==References==<br />
<references/><br />
<br />
[[Category:Exchanges]]<br />
[[Category:eWallets]]</div>Amincdhttps://en.bitcoin.it/w/index.php?title=Template:MainPage_Topics&diff=18081Template:MainPage Topics2011-10-15T03:29:41Z<p>Amincd: </p>
<hr />
<div><!--<br />
First table is for tutorials. Left column = pages written for end users. Right column = pages for developers.<br />
Second table is for categories.<br />
--><br />
<br />
{|cellpadding="2" style="background-color: inherit;"<br />
|-<br />
| scope="col" style="width: 200px;" |<br />
* [[Introduction]]<br />
* [[Getting started]]<br />
* [[Myths]]<br />
* [[Securing your wallet]]<br />
| scope="col" style="width: 200px;" |<br />
* [[PHP developer intro]]<br />
* [[API reference (JSON-RPC)]]<br />
* [[Protocol specification]]<br />
* [[Secure Trading|Best practices for traders]]<br />
* [[Bitcoin Improvement Proposals]]<br />
|}<br />
<br />
{|cellpadding="2" style="background-color: inherit;"<br />
|-<br />
! scope="col" style="width: 200px;" |<br />
! scope="col" style="width: 200px;" |<br />
|-<br />
|<br />
* [[Software]]<br />
* [[:Category:Mining|Mining]]<br />
* [[:Category:Exchanges|Exchanges]]<br />
* [[:Category:Directories|Local Directories]]<br />
* [[Press|Press coverage]]<br />
* [[:Category:Marketing|Marketing resources]]<br />
* [[People]]<br />
|<br />
* [[:Category:Technical|Technical articles]]<br />
* [[:Category:Clients|Clients]] / [[:Category:Frontends|Frontends]]<br />
* [[:Category:Economics|Economics]]<br />
* [[Trade|Trade]]<br />
* [[Real world shops|Real world merchants map]]<br />
* [[Donation-accepting_organizations_and_projects|Donation-accepting sites]]<br />
* [[Meetups]]<br />
|}<br />
<br />
<div style="text-align: right;" class="noprint"><span class="plainlinks">[{{fullurl:Template:MainPage_Topics|action=edit}} '''Edit''']</span> &ndash; '''[[Special:Categories|See More]]'''</div></div>Amincdhttps://en.bitcoin.it/w/index.php?title=Promotional_graphics&diff=16838Promotional graphics2011-09-18T13:55:32Z<p>Amincd: </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 />
<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>Amincdhttps://en.bitcoin.it/w/index.php?title=File:GoldenAcceptedHereBitcoin.png&diff=16837File:GoldenAcceptedHereBitcoin.png2011-09-18T13:55:26Z<p>Amincd: </p>
<hr />
<div></div>Amincdhttps://en.bitcoin.it/w/index.php?title=Promotional_graphics&diff=16828Promotional graphics2011-09-18T11:03:59Z<p>Amincd: </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 />
<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}}:GoldenBitcoin.jpg]]<br />
<br />
<br />
* [[{{ns:file}}:GoldenBitcoinGreyOrangeHorizontal.jpg]]<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>Amincdhttps://en.bitcoin.it/w/index.php?title=File:GoldenBitcoin.jpg&diff=16827File:GoldenBitcoin.jpg2011-09-18T11:01:31Z<p>Amincd: </p>
<hr />
<div>== Licensing ==<br />
{{self|Cc-zero}}</div>Amincdhttps://en.bitcoin.it/w/index.php?title=File:GoldenBitcoinGreyOrangeHorizontal.jpg&diff=16826File:GoldenBitcoinGreyOrangeHorizontal.jpg2011-09-18T11:00:59Z<p>Amincd: </p>
<hr />
<div>== Licensing ==<br />
{{self|Cc-zero}}</div>Amincdhttps://en.bitcoin.it/w/index.php?title=Btcnow&diff=16260Btcnow2011-09-07T08:26:47Z<p>Amincd: Created page with "Allows the purchase of Bitcoin through Google Checkout. ==External Links== http://btcnow.net Category:Exchanges"</p>
<hr />
<div>Allows the purchase of Bitcoin through Google Checkout.<br />
<br />
==External Links==<br />
<br />
http://btcnow.net<br />
<br />
[[Category:Exchanges]]</div>Amincd