https://en.bitcoin.it/w/api.php?action=feedcontributions&user=Lapp0&feedformat=atomBitcoin Wiki - User contributions [en]2024-03-28T15:26:37ZUser contributionsMediaWiki 1.30.0https://en.bitcoin.it/w/index.php?title=Bitcoin_XT&diff=60008Bitcoin XT2016-01-20T05:35:27Z<p>Lapp0: "unusually" doesn't make sense in this context</p>
<hr />
<div>{{infobox software|logo=[[File:xt.png|256px]]|image=[[File:bitcoinxt.png|256px]]|caption=The identifying marks of an XT client<br />
|bg=orange<br />
|author=[[Gavin Andresen]]<br/>[[Mike Hearn]]<br />
|website=[https://bitcoinxt.software bitcoinxt.software]<br />
}}'''Bitcoin XT''' is a fork of [[Bitcoin Core]] that aims to make transactions reliable, inexpensive, and accessible. It achieved significant notoriety and support after prematurely adopting [[BIP 0101|BIP 101]], giving it importance in the [[block size limit controversy]].<ref name="ooc">{{cite web|work=[[The Neighbourhood Pool Watch]]|author=[[organofcorti]]|title=BIP101 implementation flaws|date=27 August 2015|accessdate=27 August 2015|url=http://organofcorti.blogspot.com/2015/08/bip101-implementation-flaws.html}}</ref><br />
<br />
After [[Gavin Andresen]]'s resignation from the position of [[Bitcoin Core]] maintainer, he and [[Mike Hearn]] organized{{when}} Bitcoin XT to address controversial ideas lacking the consensus required to be implemented in Bitcoin Core.<ref>{{cite web|work=Medium|title=An XT FAQ|author=[[Mike Hearn|Hearn, Mike]]|date=27 August 2015|accessdate=27 August 2015|url=https://medium.com/@octskyward/an-xt-faq-38e78aa32ff0}}</ref><br />
<br />
Due to implementing BIP 0101 in version 0.11.0A, it is now incompatible with the Bitcoin consensus protocol, and when 75% of the last 1000 blocks are observed to have particular version bits set, it ceases enforcing the 1 MB block size limit and also adds a few new rules.<br />
Since it is incompatible with the Bitcoin protocol, it is technically an [[altcoin]], however, if it were to obtain [[Economic_majority|economic acceptance]] it would become a "new Bitcoin" some day.<br />
<br />
==Mission statement==<br />
<!--this needs to be summarized or removed--><br />
The XT mission statement defines what the project believes is important: commitment to these principles are what differentiates it from Bitcoin Core.<br />
<br />
* '''Scaling the network up to handle user demand and spam is important''', even if that means the network becomes centralised along the way. The idea of a global system used by ordinary people is what motivated many people to support this.<br />
* XT proponents believe '''unconfirmed transactions are important'''. Many merchants want or need to accept payments within seconds rather than minutes or hours. XT accepts this fact and does what it can to minimise the risk, then "helps" sellers judge what remains. It is committed to support only "first seen" policies, and will not adopt changes that make unconfirmed transactions riskier.<br />
<!-- This doesn't seem different from Core: ** '''Lightweight wallets are important'''. Most users cannot or will not run a fully verifying node. Most of the world population does not even own a computer: they will experience the internet exclusively via smartphones. These users must sacrifice some security in order to participate, so XT supports whatever technical tradeoffs wallet developers wish to explore. --><br />
* '''Decision making is quick and clear'''. Decisions are made according to a leadership hierarchy. The XT software encodes decisions that follow the above principles: people who disagree are welcome to use different software, or patch ours. We do not consider writing principled software to be centralising and do not refuse to select reasonable defaults.<br />
<!-- Also no difference: * The Bitcoin XT community is friendly, pragmatic, cares about app developers and considers the user experience in everything we do. We value professionalism in technical approach and communication. We run a moderated mailing list and do not tolerate troublemakers. --><br />
<br />
You can [https://bitcoinxt.software/patches.html read more about the code changes in Bitcoin XT]. <br />
<br />
==Block size hard fork==<br />
In 2010, a block size limit was introduced into Bitcoin by [[Satoshi Nakamoto]]. He added it as a safety measure to prevent miners from spamming large blocks and meant for it to be removed once secure lightweight wallets were developed;<br />
however, the spam problem has only gotten worse, and secure lightweight wallets never implemented.<br />
<br />
There has been much community [[Block size limit controversy|debate]] on this topic. You can read analysis and explanations for why we think raising the block size limit is important here: <br />
<br />
* [http://gavinandresen.ninja/ A series of essays] by [[Gavin Andresen]]<br />
* [https://medium.com/@octskyward/crash-landing-f5cc19908e32 Why the block size limit must be raised] and [https://medium.com/@octskyward/the-capacity-cliff-586d1bf7715e why the proposed alternative schemes will not work], by [[Mike Hearn]].<br />
<br />
==Miners==<br />
Miners that side with Bitcoin XT will produce blocks with a new version number.<ref name="avc">{{cite web|title=The Bitcoin XT Fork|work=AVC|author=Wilson, Fred|date=17 August 2015|accessdate=28 August 2015|url=http://avc.com/2015/08/the-bitcoin-xt-fork/}}</ref> This indicates to the rest of the network that they support XT.<ref name="avc"/> When 75% of the last 1000 blocks are new-version blocks, these miners will automatically abandon Bitcoin and begin mining on a new Bitcoin XT blockchain.<ref name="avc"/> This will begin after a waiting period of two weeks in hopes the economy in this time may force anyone who hasn't switched yet to do so.<ref name="avc"/><br />
<br />
Users and miners running full Bitcoin nodes will reject the XT blockchain starting with the first block that is larger than one megabyte in size, and thus be unaffected provided it fails to achieve economic consensus.<br />
<br />
==Users and merchants==<br />
If insufficient mining hash power runs XT to reach supermajority then nothing will happen. If enough does, XT users will follow a new blockchain and cease to be using and trading bitcoins.<br />
<br />
==See Also==<br />
* [[BIP 0101]]<br />
* [[Scalability FAQ]]<br />
<br />
==References==<br />
<references/><br />
<br />
[[Category:Block size limit controversy]]<br />
[[Category:Direct code forks of Bitcoin Core]]<br />
[[Category:User Interfaces]]<br />
[[Category:Frontends]]<br />
[[Category:Free Software]]<br />
[[Category:Open Source]]</div>Lapp0https://en.bitcoin.it/w/index.php?title=Talk:Bitcoin_XT&diff=60007Talk:Bitcoin XT2016-01-20T05:33:23Z<p>Lapp0: </p>
<hr />
<div>{{WikiProject|Protocol|importance=HIGH|quality=START}}<br />
<br />
Hello, <br />
<br />
I think the last paragraph is not 100% correct ( "XT users will follow a new blockchain and cease to be using and trading bitcoins." )<br />
<br />
only if there is a fork _without_ economic majority this would be the case. I tried to make it more factual but my edit got reverted,<br />
maybe it was also not 100% correct, but the current text is also wrong and sounds like FUD imho.<br />
<br />
:Hash power doesn't imply an economic majority. If a hash power majority decides on something that merchants don't recognize then the fork is completely irrelevant. ---[[User:Lapp0|Lapp0]] ([[User talk:Lapp0|talk]])</div>Lapp0https://en.bitcoin.it/w/index.php?title=Bitcoin_XT&diff=59837Bitcoin XT2016-01-07T00:59:45Z<p>Lapp0: Reverted incorrect statements</p>
<hr />
<div>{{infobox software|logo=[[File:xt.png|256px]]|image=[[File:bitcoinxt.png|256px]]|caption=The identifying marks of an XT client<br />
|bg=orange<br />
|author=[[Gavin Andresen]]<br/>[[Mike Hearn]]<br />
|website=[https://bitcoinxt.software bitcoinxt.software]<br />
}}'''Bitcoin XT''' is a fork of [[Bitcoin Core]] that aims to make transactions reliable, inexpensive, and accessible. It achieved significant notoriety and support after prematurely adopting [[BIP 0101|BIP 101]], giving it importance in the [[block size limit controversy]].<ref name="ooc">{{cite web|work=[[The Neighbourhood Pool Watch]]|author=[[organofcorti]]|title=BIP101 implementation flaws|date=27 August 2015|accessdate=27 August 2015|url=http://organofcorti.blogspot.com/2015/08/bip101-implementation-flaws.html}}</ref><br />
<br />
After [[Gavin Andresen]]'s resignation from the position of [[Bitcoin Core]] maintainer, he and [[Mike Hearn]] organized{{when}} Bitcoin XT to address controversial ideas lacking the consensus required to be implemented in Bitcoin Core.<ref>{{cite web|work=Medium|title=An XT FAQ|author=[[Mike Hearn|Hearn, Mike]]|date=27 August 2015|accessdate=27 August 2015|url=https://medium.com/@octskyward/an-xt-faq-38e78aa32ff0}}</ref><br />
<br />
Due to implementing BIP 0101 in version 0.11.0A, it is now incompatible with the Bitcoin consensus protocol, and when 75% of the last 1000 blocks are observed to have particular version bits set, it ceases enforcing the 1 MB block size limit and also adds a few new rules.<br />
Since it is incompatible with the Bitcoin protocol, it is technically an [[altcoin]], but due to an unusually large economic acceptance it may potentially become a "new Bitcoin" some day.<br />
<br />
==Mission statement==<br />
<!--this needs to be summarized or removed--><br />
The XT mission statement defines what the project believes is important: commitment to these principles are what differentiates it from Bitcoin Core.<br />
<br />
* '''Scaling the network up to handle user demand and spam is important''', even if that means the network becomes centralised along the way. The idea of a global system used by ordinary people is what motivated many people to support this.<br />
* XT proponents believe '''unconfirmed transactions are important'''. Many merchants want or need to accept payments within seconds rather than minutes or hours. XT accepts this fact and does what it can to minimise the risk, then "helps" sellers judge what remains. It is committed to support only "first seen" policies, and will not adopt changes that make unconfirmed transactions riskier.<br />
<!-- This doesn't seem different from Core: ** '''Lightweight wallets are important'''. Most users cannot or will not run a fully verifying node. Most of the world population does not even own a computer: they will experience the internet exclusively via smartphones. These users must sacrifice some security in order to participate, so XT supports whatever technical tradeoffs wallet developers wish to explore. --><br />
* '''Decision making is quick and clear'''. Decisions are made according to a leadership hierarchy. The XT software encodes decisions that follow the above principles: people who disagree are welcome to use different software, or patch ours. We do not consider writing principled software to be centralising and do not refuse to select reasonable defaults.<br />
<!-- Also no difference: * The Bitcoin XT community is friendly, pragmatic, cares about app developers and considers the user experience in everything we do. We value professionalism in technical approach and communication. We run a moderated mailing list and do not tolerate troublemakers. --><br />
<br />
You can [https://bitcoinxt.software/patches.html read more about the code changes in Bitcoin XT]. <br />
<br />
==Block size hard fork==<br />
In 2010, a block size limit was introduced into Bitcoin by [[Satoshi Nakamoto]]. He added it as a safety measure to prevent miners from spamming large blocks and meant for it to be removed once secure lightweight wallets were developed;<br />
however, the spam problem has only gotten worse, and secure lightweight wallets never implemented.<br />
<br />
There has been much community [[Block size limit controversy|debate]] on this topic. You can read analysis and explanations for why we think raising the block size limit is important here: <br />
<br />
* [http://gavinandresen.ninja/ A series of essays] by [[Gavin Andresen]]<br />
* [https://medium.com/@octskyward/crash-landing-f5cc19908e32 Why the block size limit must be raised] and [https://medium.com/@octskyward/the-capacity-cliff-586d1bf7715e why the proposed alternative schemes will not work], by [[Mike Hearn]].<br />
<br />
==Miners==<br />
Miners that side with Bitcoin XT will produce blocks with a new version number.<ref name="avc">{{cite web|title=The Bitcoin XT Fork|work=AVC|author=Wilson, Fred|date=17 August 2015|accessdate=28 August 2015|url=http://avc.com/2015/08/the-bitcoin-xt-fork/}}</ref> This indicates to the rest of the network that they support XT.<ref name="avc"/> When 75% of the last 1000 blocks are new-version blocks, these miners will automatically abandon Bitcoin and begin mining on a new Bitcoin XT blockchain.<ref name="avc"/> This will begin after a waiting period of two weeks in hopes the economy in this time may force anyone who hasn't switched yet to do so.<ref name="avc"/><br />
<br />
Users and miners running full Bitcoin nodes will reject the XT blockchain starting with the first block that is larger than one megabyte in size, and thus be unaffected provided it fails to achieve economic consensus.<br />
<br />
==Users and merchants==<br />
If insufficient mining hash power runs XT to reach supermajority then nothing will happen. If enough does, XT users will follow a new blockchain and cease to be using and trading bitcoins.<br />
<br />
==See Also==<br />
* [[BIP 0101]]<br />
* [[Scalability FAQ]]<br />
<br />
==References==<br />
<references/><br />
<br />
[[Category:Block size limit controversy]]<br />
[[Category:Direct code forks of Bitcoin Core]]<br />
[[Category:User Interfaces]]<br />
[[Category:Frontends]]<br />
[[Category:Free Software]]<br />
[[Category:Open Source]]</div>Lapp0https://en.bitcoin.it/w/index.php?title=Bitcoin_XT&diff=59478Bitcoin XT2015-12-03T04:12:33Z<p>Lapp0: "Proponent of controversy" isn't the correct way to phrase this</p>
<hr />
<div>{{infobox software|logo=[[File:xt.png|256px]]|image=[[File:bitcoinxt.png|256px]]|caption=The identifying marks of an XT client<br />
|bg=orange<br />
|author=[[Gavin Andresen]]<br/>[[Mike Hearn]]<br />
|website=[https://bitcoinxt.software bitcoinxt.software]<br />
}}'''Bitcoin XT''' is a fork of [[Bitcoin Core]] that aims to make transactions reliable, inexpensive, and accessible. It achieved significant notoriety and support after prematurely adopting [[BIP 0101|BIP 101]], giving it importance in the [[block size limit controversy]].<ref name="ooc">{{cite web|work=[[The Neighbourhood Pool Watch]]|author=[[organofcorti]]|title=BIP101 implementation flaws|date=27 August 2015|accessdate=27 August 2015|url=http://organofcorti.blogspot.com/2015/08/bip101-implementation-flaws.html}}</ref><br />
<br />
After [[Gavin Andresen]]'s resignation from the position of [[Bitcoin Core]] maintainer, he and [[Mike Hearn]] organized{{when}} Bitcoin XT to address controversial ideas lacking the consensus required to be implemented in Bitcoin Core.<ref>{{cite web|work=Medium|title=An XT FAQ|author=[[Mike Hearn|Hearn, Mike]]|date=27 August 2015|accessdate=27 August 2015|url=https://medium.com/@octskyward/an-xt-faq-38e78aa32ff0}}</ref><br />
<br />
Due to implementing BIP 0101 in version 0.11.0A, it is now incompatible with the Bitcoin consensus protocol, and when 75% of the last 1000 blocks are observed to have particular version bits set, it ceases enforcing the 1 MB block size limit and also adds a few new rules.<br />
Since it is incompatible with the Bitcoin protocol, it is technically an [[altcoin]], but due to an unusually large economic acceptance it may potentially become a "new Bitcoin" some day.<br />
<br />
==Mission statement==<br />
<!--this needs to be summarized or removed--><br />
The XT mission statement defines what the project believes is important: commitment to these principles are what differentiates it from Bitcoin Core.<br />
<br />
* '''Scaling the network up to handle user demand and spam is important''', even if that means the network becomes centralised along the way. The idea of a global system used by ordinary people is what motivated many people to support this.<br />
* XT proponents believe '''unconfirmed transactions are important'''. Many merchants want or need to accept payments within seconds rather than minutes or hours. XT accepts this fact and does what it can to minimise the risk, then "helps" sellers judge what remains. It is committed to support only "first seen" policies, and will not adopt changes that make unconfirmed transactions riskier.<br />
<!-- This doesn't seem different from Core: ** '''Lightweight wallets are important'''. Most users cannot or will not run a fully verifying node. Most of the world population does not even own a computer: they will experience the internet exclusively via smartphones. These users must sacrifice some security in order to participate, so XT supports whatever technical tradeoffs wallet developers wish to explore. --><br />
* '''Decision making is quick and clear'''. Decisions are made according to a leadership hierarchy. The XT software encodes decisions that follow the above principles: people who disagree are welcome to use different software, or patch ours. We do not consider writing principled software to be centralising and do not refuse to select reasonable defaults.<br />
<!-- Also no difference: * The Bitcoin XT community is friendly, pragmatic, cares about app developers and considers the user experience in everything we do. We value professionalism in technical approach and communication. We run a moderated mailing list and do not tolerate troublemakers. --><br />
<br />
You can [https://bitcoinxt.software/patches.html read more about the code changes in Bitcoin XT]. <br />
<br />
==Block size hard fork==<br />
In 2010, a block size limit was introduced into Bitcoin by [[Satoshi Nakamoto]]. He added it as a safety measure to prevent miners from spamming large blocks and meant for it to be removed once secure lightweight wallets were developed;<br />
however, the spam problem has only gotten worse, and secure lightweight wallets never implemented.<br />
<br />
There has been much community [[Block size limit controversy|debate]] on this topic. You can read analysis and explanations for why we think raising the block size limit is important here: <br />
<br />
* [http://gavinandresen.ninja/ A series of essays] by [[Gavin Andresen]]<br />
* [https://medium.com/@octskyward/crash-landing-f5cc19908e32 Why the block size limit must be raised] and [https://medium.com/@octskyward/the-capacity-cliff-586d1bf7715e why the proposed alternative schemes will not work], by [[Mike Hearn]].<br />
<br />
==Miners==<br />
Miners that side with Bitcoin XT will produce blocks with a new version number.<ref name="avc">{{cite web|title=The Bitcoin XT Fork|work=AVC|author=Wilson, Fred|date=17 August 2015|accessdate=28 August 2015|url=http://avc.com/2015/08/the-bitcoin-xt-fork/}}</ref> This indicates to the rest of the network that they support XT.<ref name="avc"/> When 75% of the last 1000 blocks are new-version blocks, these miners will automatically abandon Bitcoin and begin mining on a new Bitcoin XT blockchain.<ref name="avc"/> This will begin after a waiting period of two weeks in hopes the economy in this time may force anyone who hasn't switched yet to do so.<ref name="avc"/><br />
<br />
Users and miners running full Bitcoin nodes will reject the XT blockchain starting with the first block that is larger than one megabyte in size, and thus be unaffected provided it fails to achieve economic consensus.<br />
<br />
==Users and merchants==<br />
If insufficient mining hash power runs XT to reach supermajority then nothing will happen. If enough does, XT users will follow a new blockchain and cease to be using and trading bitcoins.<br />
<br />
==See Also==<br />
* [[BIP 0101]]<br />
* [[Scalability FAQ]]<br />
<br />
==References==<br />
<references/><br />
<br />
[[Category:Block size limit controversy]]<br />
[[Category:Direct code forks of Bitcoin Core]]<br />
[[Category:User Interfaces]]<br />
[[Category:Frontends]]<br />
[[Category:Free Software]]<br />
[[Category:Open Source]]</div>Lapp0https://en.bitcoin.it/w/index.php?title=Roger_Ver&diff=59448Roger Ver2015-11-30T13:06:00Z<p>Lapp0: </p>
<hr />
<div>{{infobox person|name=Roger Ver<br />
|names=Bitcoin Jesus<br />
|bitcointalk=[https://bitcointalk.org/index.php?action=profile;u=10310 10310]<br />
}}'''Roger Ver''', sometimes dubbed '''Bitcoin Jesus''', is the founder and CEO of [https://memorydealers.com/ MemoryDealers], and a Bitcoin evangelist.<br />
<br />
[[image:memorydealers_roadsign.jpg|thumb|A June 2011 billboard promoting Bitcoin paid for by Roger Ver]]<br />
<br />
He is one of [[BitPay]]'s investors, and was involved/invested with [[BlockChain.info]]/MyWallet as well.<br />
<br />
In 2002 Ver plead guilty to selling explosives on eBay.<ref>[http://web.archive.org/web/20150213142114/http://www.justice.gov/criminal/cybercrime/press-releases/2002/verPlea.htm San Jose, California Man Pleads Guilty to Selling Explosives on eBay (May 2, 2002)]</ref><br />
== See also ==<br />
* http://www.crunchbase.com/person/roger-ver<br />
<br />
[[Category:people]]<br />
<br />
==References==<br />
<references/><br />
{{stub}}</div>Lapp0https://en.bitcoin.it/w/index.php?title=Softfork&diff=59153Softfork2015-10-21T00:17:05Z<p>Lapp0: typo, rephrasing</p>
<hr />
<div>A softfork is a change to the bitcoin protocol wherein only previously valid blocks/transactions are made invalid.<br />
Since old nodes will recognise the new blocks as valid, a softfork is backward-compatible.<br />
This kind of fork requires only a majority of the miners upgrading to enforce the new rules.<br />
<br />
New transaction types can often be added as softforks, requiring only that the participants (sender and receiver) and miners understand the new transaction type.<br />
This is done by having the new transaction appear to older clients as a "pay-to-anybody" transaction (of a special form), and getting the miners to agree to reject blocks including these transaction unless the transaction validates under the new rules.<br />
This is how [[P2SH]] was added to Bitcoin.<br />
<br />
==Mechanism==<br />
<br />
Given a set of valid blocks, you can take any subset of those blocks and that subset will also, of course, all be valid. A softfork changes the rules such that only a subset of blocks that were previously valid remain so. Often softforks make certain transactions invalid, for example a softfork could make any transaction that is more than 1KB invalid (not that that would necessarily be desirable).<br />
<br />
Generally softforks accomplish something more useful, for example Pay-to-Script-Hash ([[P2SH]]) was a softfork. Originally the script "OP_HASH160 [20-byte-hash-value] OP_EQUAL" could be redeemed by simply pushing the preimage of the hashed value onto the stack. Now the value you push must be a script that evaluates to true. All new transactions with the script "OP_HASH160 [20-byte-hash-value] OP_EQUAL" weren't valid if they merely had a preimage of the hash pushed onto the stack, the preimage had to be a valid script. The requirement for the preimage being a valid script shrunk the set of valid transactions and added a feature at the same time.<br />
<br />
In the P2SH example, two opcodes were redefined so they had a new function. You can also add new opcodes that originally didn't do anything. Because the new rules must cause the set of valid blocks to be a proper subset of the valid blocks with the old rules, you must ensure that adding this new opcode doesn't cause transactions that were once invalid to be valid. In [[BIP12]] OP_EVAL is proposed. To softfork this new opcode in, the proposal stated an opcode that previously didn't have any effect would be replaced. The script would be evaluated twice, once with the opcode having the new OP_EVAL behavior and once with it's old behavior of doing nothing. The script being run with the old behavior of doing nothing would ensure that the transaction was valid to old clients.<br />
<br />
==Security==<br />
<br />
In order for a softfork to work, a majority of the mining power needs to be running a client recognizing the fork. The more miners that accept the new rules, the more secure the network is post-fork. If you have 3/4 of miners recognizing the fork, 1/4 blocks created aren't guaranteed to follow the new rules. These 1/4 blocks will be valid to old nodes that aren't aware of the new rules, but they will be ignored by new nodes. This allows a "fake confirmation" vulnerability, an attacker could create a transaction paying to their victim, but have it end up in a block not following new rules, they might bribe a miner to make the block incompatible with new rules or make the transaction itself incompatible. Because 3/4 the hashrate won't mine on top of the block, the block and the transaction paying to you will eventually not be in the "mainchain" allowing the attacker to attempt to [[Double-spending|doublespend]].<br />
<br />
These attacks can be avoided by upgrading your client, however if the vast majority of miners (>95%) accept the new rules, the odds of an attacker being able to create many fake confirmations is low. Because miners want to make money, and without upgrading their blocks may be reorged out, there is an incentive for miners to upgrade and 100% acceptance of a fork should be achieved by miners quickly.<br />
<br />
===2015 BIP66 Blockchain Fork===<br />
<br />
After the deployment of the BIP66 softfork in 2015 95% of hash power stated that they accepted BIP66 by setting their block version to 3. In theory setting your block version to 3 is an agreement with the network to consider version 2 blocks invalid and only mine on valid forks. Being part of the 5% that hadn't updated and weren't creating version 3 blocks, BTCNuggets created a version 2 block which was invalid to all new clients (>=0.9.5) but valid to old clients. Antminer and F2Pool, comprising ~40% of the network at the time, were creating version 3 blocks, however neither miner validated previous blocks. This caused both Antminer and F2Pool to mine on top of BTCNuggets version 2 block and create an invalid fork. Over 40% of the hashpower was mining on this version 2 fork despite 95% having "agreed" to not do so. This led to a 6 block fork that was resolved after contacting the F2Pool and Antminer pool owners.<br />
<br />
Any SPV clients or out of date clients were vulnerable to these fake confirmations and in theory there could have been a reversed 6 confirmation transaction. Fortunately there were zero doublespent confirmed transactions and the only money lost was mining revenue that these pools lost. F2Pool has continued mining without validating beforehand and SPV client as well as outdated full node clients are at an even higher risk as long as they do so.<br />
<br />
==Implications==<br />
<br />
Softforks don't require any nodes to upgrade to maintain consensus since all blocks with the new softforked in rules also follow the old rules, therefore old clients accept them. Softforks cannot be reversed without a hardfork since a softfork by definition only allows the set of valid blocks to be a proper subset of what was valid pre-fork.<br />
<br />
If users upgrade to a post-softfork client and for some reason a majority of miners switch back to the pre-softfork client, the post-softfork client users would break consensus as soon as a block came along that didn't follow their clients new rules.<br />
<br />
See also: [[Hardfork]]</div>Lapp0https://en.bitcoin.it/w/index.php?title=Scalability&diff=59152Scalability2015-10-21T00:14:53Z<p>Lapp0: As explained, this page isn't about scaling the Bitcoin network and security concerns, rather scaling an individual Bitcoin client while not considering the effects on the network.</p>
<hr />
<div>A Bitcoin full node could be modified to scale to much higher transaction rates than are seen today, assuming that said node is running on a high end servers rather than a desktop. 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).<br />
<br />
''Please note that this page exists to give calculations about the scalability of a Bitcoin full node and transactions on the block chain without regards to network security. It is not intended to discuss the scalability of alternative protocols or try and summarise philosophical debates. Create alternative pages if you want to do that.''<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, handled around 10 million transactions per day for an average of 115 tps in late 2014. [https://web.archive.org/web/20141226073503/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 />
===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 2015 the network is handling 1.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. Once hard disks are phased out in favour of SSDs, it is quite possible that access to the UTXO set never becomes a serious bottleneck.<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 />
* [https://lightning.network/ Lightning Network], an alternative protocol for transaction clearance in which payment hubs set up micropayment channels between each other and settle up on the block chain occasionally. Ordinary users interact primarily or only with hubs.<br />
<br />
[[Category:Technical]]</div>Lapp0https://en.bitcoin.it/w/index.php?title=Block_size_limit_controversy&diff=58725Block size limit controversy2015-09-11T20:16:29Z<p>Lapp0: </p>
<hr />
<div>{{current}}{{see also|Scalability FAQ}}<br />
[[Block]]s are limited to 1MB in size. Miners can mine blocks up to the 1MB fixed limit, but any block larger than 1MB is invalid. This limit cannot be modified without a hard fork. To prevent Bitcoin from temporarily or permanently splitting into separate payment networks ("altcoins"), hard forks require adoption by nearly all [[Full node#Economic_strength|economically active]] full nodes.<br />
<br />
== Arguments in favor of increasing the blocksize ==<br />
* More transactions per second<br />
* Off-chain solutions are not yet ready to take off the load from the main blockchain.<br />
<br />
== Contentions ==<br />
* Increased blocksize will leave space for extensions like Mastercoin, Counterparty, etc.<br />
** Neutral: Bitcoin competitors will have lower fees<br />
** Negative: Bitcoin full nodes are forced to use more resources that don't support Bitcoin<br />
* Small blocks eventually will require higher fees for fast confirmations.<br />
** Positive: It will no longer be cheap to spam transactions such as Satoshi Dice bets<br />
** Positive: Fees will not be zero. This is eventually a necessity in order to incentivize miners and secure the mining ecosystem<br />
** Negative: Bitcoin may look unattractive to new users with high fees<br />
** Negative: High fees may stop or reverse global adoption, investment, development, support and centralization{{clarification needed}}<br />
** Negative: Bitcoin users pay higher fees<br />
* A low blocksize limit encourages higher transactions fees to incentivize miners ("let a fee market develop"). <br />
** A fee market naturally develops due to miner latency regardless<ref>https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf A Transaction Fee Market Exists Without a Block Size Limit</ref><br />
*** The relay network can be optimized so that miners don't have a stale rate increasing with latency. This should cause the fee market to once again require a block size limit to exist.<br />
<br />
== Arguments in opposition to increasing the blocksize ==<br />
* A hard fork requires waiting for sufficient consensus.<br />
* Risk of catastrophic consensus failure<ref>https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html</ref>{{clarification needed}}<br />
* An emergency hard fork that can achieve consensus can be deployed on a short time period if needed.<ref>[https://www.reddit.com/r/Bitcoin/comments/392m43/mike_hearn_blocksize_debate_at_the_breaking_point/cs00wdd How to raise block size in a short time], Peter Todd, Reddit /r/Bitcoin, 9 June 2015</ref><br />
* Orphan rate amplification, more reorgs and double-spends due to slower propagation speeds.<br />
* European/American pools at more of a disadvantage compared to the Chinese pools{{why}}<br />
* "Congestion" concerns can be solved with mempool improvements including transaction eviction.<br />
* No amount of max block size would support all the world's future transactions on the main blockchain (various types of off-chain transactions are the only long-term solution)<br />
* Fast block propagation is either not clearly viable, or (eg, IBLT) creates centralised controls.<br />
<br />
=== Damage to decentralization ===<br />
* Larger blocks make full nodes more expensive to operate.<br />
* Therefore, larger blocks lead to less hashers running full nodes, which leads to centralized entities having more power, which makes Bitcoin require more trust, which weakens Bitcoins value proposition.<br />
* Bitcoin is only useful if it is decentralized because centralization requires trust. Bitcoins value proposition is trustlessness.<br />
* The larger the hash-rate a single miner controls, the more centralized Bitcoin becomes and the more trust using Bitcoin requires.<br />
* Running your own full node while mining rather than giving another entity the right to your hash-power decreases the hash-rate of large miners. Those who have hash-power are able to control their own hash power if and only if they run a full node.<br />
* Less individuals who control hash-power will run full nodes if running one becomes more expensive<ref>https://www.weusecoins.com/why-blocksize-limit-keeps-bitcoin-free-decentralized/</ref>.<br />
<br />
==Proposals==<br />
===BIP 100===<br />
Change block size limit based on miner votes, but don't leave the range (1MB, 32MB) without a softfork or hardfork respectively.<br />
===BIP 101===<br />
{{seealso|Bitcoin XT}}<br />
Increase to 8 MB after both January 11, 2016 has passed and 75% of miners are supporting. Double the limit every two years with the size increasing linearly within those two year intervals.<br />
===BIP 102===<br />
Increase to 2 MB on November 11, 2015.<br />
===BIP 103===<br />
Increase by 17.7% annually until 2063.<br />
<br />
== Entities positions ==<br />
Positions below are based on a suggested fixed block size increase to 20MiB. Positions against these larger blocks do not necessarily imply that they are against an increase in general, and may instead support a smaller and/or gradual increase.<br />
{| class="wikitable sortable"<br />
! Entity<br />
! Supports Larger Blocks<br />
! Supports Hard Fork<br />
|-<br />
| Bitcoinpaygate<br />
| {{No|No: "We do NOT support the blocksize increase"}}<ref>http://www.reddit.com/r/Bitcoin/comments/37y8wm/list_of_bitcoin_services_that_supportoppose/crqsnqp</ref><br />
|<br />
|-<br />
| Bitrated<br />
| {{No}}<br />"At this time, I oppose increasing the block size limit as per Gavin's proposal" - Nadav Ivgi (founder)<ref>https://twitter.com/shesek/status/605005384026177537</ref><br />
|<br />
|-<br />
| [[GreenAddress]]<br />
| {{No|No: "In our mind increasing the block size like this is just pushing the problem a little further at potentially unfixable costs."}}<ref>http://www.reddit.com/r/Bitcoin/comments/35anax/list_of_bitcoin_services_that_support_increasing/cr2mq84</ref><br />
|<br />
|-<br />
| [[MPEx]]<br />
| {{No}}<ref>http://log.bitcoin-assets.com//?date=07-01-2015#967332</ref><br />
|<br />
|-<br />
| [[Paymium]]<br />
| {{No|No: "<nowiki>[allow]</nowiki> a sane transaction fee market to emerge, by letting the blocks actually fill-up."}} - CTO David Francois<ref>http://fr.anco.is/2015/gavineries/</ref><br />
| <br />
|-<br />
| Ethereum<br /><br />
| {{Neutral|Neutral: "If <nowiki>[the niche of digital gold]</nowiki> is what Bitcoin users want, then they should keep the limit, and perhaps even decrease it. But if Bitcoin users want to be a payment system, then up it must go."}} - Vitalik Buterin (founder)<ref>http://www.reddit.com/r/ethereum/comments/380q61/i_know_this_may_not_directly_be_ethereum_related/crrofl6</ref><br />
|<br />
|-<br />
| [[F2Pool]]<br />
| {{Neutral|Neutral: "We do support bigger blocks and sooner rather than later. But we cannot handle 20 MB blocks right now. ... I think we can accept 5MB block at most."}}<ref>http://sourceforge.net/p/bitcoin/mailman/message/34157036/],[http://sourceforge.net/p/bitcoin/mailman/message/34158911/</ref><br />
|<br />
|-<br />
| [[Armory]]<br />
| {{Yes}}<br />"This *is* urgent and needs to be handled right now, and I believe Gavin<br />
has the best approach to this." - CEO Alan Reiner<ref>http://sourceforge.net/p/bitcoin/mailman/message/34093337/</ref><br />
|<br />
|-<br />
| BitcoinReminder<br />
| {{Yes|Yes: "BitcoinReminder.com also supports 20MB blocks (or even more?"}}<ref>http://www.reddit.com/r/Bitcoin/comments/37y8wm/list_of_bitcoin_services_that_supportoppose/crs9ytd</ref><br />
|<br />
|-<br />
| BitHours<br />
| {{Yes|Yes: "We support @gavinandresen and his proposal for 20mb blocks"}}<ref>https://twitter.com/bithours/status/605131647747358721</ref><br />
|<br />
|-<br />
| [[BitPay]]<br />
| {{Yes}}<br />"Agreed (but optimistic this will be the last and only time block size needs to increase)" - CEO Stephen Pair<ref>https://twitter.com/spair/status/595341090317799424</ref><br />
| {{Yes|Yes: "In summary, we believe BIP 101 will safeguard Bitcoin’s decentralized nature while providing a reliable, immediate path toward greater network throughput, and we would like to express our support for merging BIP 101 into Bitcoin Core."}} - Stephen Pair<ref>https://medium.com/@spair/increasing-the-block-size-limit-85ff236fc516</ref><br />
|-<br />
| Bittiraha.fi<br />
| {{Yes|Yes: "We are supporting increasing #Bitcoin max block size to 20MB."}}<ref>https://twitter.com/Bittirahafi/status/596682373028311040</ref><br />"I'm strongly in favor of the block size cap increase to 20MB." - CEO Henry Brade<ref>https://twitter.com/Technom4ge/status/596334370803326978</ref><br />
| {{Yes}}<br />"And I'm in favor of releasing a version with this change even with opposition." - CEO Henry Brade<ref>https://twitter.com/Technom4ge/status/596334370803326978</ref><br />
|-<br />
| [[Blockchain.info]]<br />
|{{Yes}}<br />"It is time to increase the block size. Agree with @gavinandresen" - CEO Peter Smith<ref>https://twitter.com/OneMorePeter/status/595676380320407553</ref><br />"Scaling #bitcoin is a big deal. Increase the block size." - Nic Cary<ref>https://twitter.com/niccary/status/595707211994763264</ref><br />
|<br />
|-<br />
| [[Blocktrail]]<br />
|{{Yes}}<br />"We'd love to see BIP101 with 4mb start, alternatively BIP100 with something to deal with the 21% attack could be good too."<ref>https://blog.blocktrail.com/2015/08/miners-block-size-vote-explained/</ref><br /><br />
|<br />
|-<br />
| Breadwallet<br />
| {{Yes}}<br />"[...] in support of the Gavin's 20Mb block proposal." - CEO Aaron Voisine<ref>http://sourceforge.net/p/bitcoin/mailman/message/34096857/</ref><br />
|<br />
|-<br />
| [[BTC Guild]]<br />
<br />
| {{Yes}}<br />"Needs to happen, but needs future expansion built in at a reasonable rate." - Eleuthria<ref>https://www.reddit.com/r/Bitcoin/comments/370rko/21_inc_engineer_everyone_assumes_humans_will_be/crjfnpg?context=3</ref><br />
|<br />
|-<br />
| BX.in.th<br />
| {{Yes|Yes: "<nowiki>http://BX.in.th</nowiki> will support the 20MB block size"}}<ref>https://twitter.com/BitcoinThai/status/605022509101023232</ref><br />
| <br />
|- <br />
| [[Coinbase (business)|CoinBase]]<br />
| {{Yes|Yes: "Coinbase supports increasing the maximum block size"}}<ref>https://twitter.com/coinbase/status/595741967759335426</ref><br />"Why we should increase the block size" - CEO Brian Armstrong<ref>https://twitter.com/brian_armstrong/status/595453245884997634</ref><br />
| {{Yes|Yes: "5/ hard forks probably shouldn't happen frequently, but periodically they are an elegant solution that helps bitcoin keep growing"}} - CEO Brian Armstrong<ref>https://twitter.com/brian_armstrong/status/633309671994998784</ref><br />
|- <br />
| [[Dr. Adam Back (individual)|Dr. Adam Back]]<br />
| {{Yes|Yes: "For the record I am not aware of a single person who has said they do not agree with scaling Bitcoin. Changing a constant is not the hard-part. The hard part is validating a plan and the other factors that go into it. It's not a free choice it is a security/scalability tradeoff. No one will thank us if we "scale" bitcoin but break it in hard to recover ways at the same time."}} <ref>https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html</ref><br />
| {{No}}<br />"I strongly urge that we return to the existing collaborative constructive review process that has been used for the last 4 years which is a consensus by design to prevent one rogue person from inserting a backdoor, or lobbying for a favoured change on behalf of a special interest group, or working for bad actor" - Dr. Adam Back<ref>https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html</ref><br />
|<br />
|-<br />
| Kryptoradio<br />
| {{Yes}}<br />"#Kryptoradio dev @zouppen supports 20MB block size in #bitcoin." - Joel Lehtonen<ref>https://twitter.com/koodilehto/status/596675967667568641</ref><br />
|<br />
|- <br />
| [[OKCoin]]<br />
| {{Yes|Yes: "OKCoin's tech team believes it's the right decision"}}<ref>https://twitter.com/okcoinbtc/status/598412795240009728</ref><br />
|<br />
|-<br />
| [[Third Key Solutions]]<br />
| {{Yes}}<br />"Gavin is right. The time to increase the block size limit is before transaction processing shows congestion problems." - CTO Andreas Antonopoulos<ref>https://twitter.com/aantonop/status/595601619581964289</ref><br />
|<br />
|-<br />
| [[Xapo]]<br />
| {{Yes|Yes: "One meg is not enough: Xapo supports increasing the maximum block size"}} - CEO Wences Casares<ref>https://twitter.com/wences/status/595768917907402752</ref><br />
|<br />
|}<br />
<br />
==References==<br />
<references/><br />
[[Category:2015 events]]</div>Lapp0https://en.bitcoin.it/w/index.php?title=Block_size_limit_controversy&diff=58724Block size limit controversy2015-09-11T20:09:48Z<p>Lapp0: Clarified BIP100, BIP10</p>
<hr />
<div>{{current}}{{see also|Scalability FAQ}}<br />
[[Block]]s are limited to 1MB in size. Miners can mine blocks up to the 1MB fixed limit, but any block larger than 1MB is invalid. This limit cannot be modified without a hard fork. To prevent Bitcoin from temporarily or permanently splitting into separate payment networks ("altcoins"), hard forks require adoption by nearly all [[Full node#Economic_strength|economically active]] full nodes.<br />
<br />
== Arguments in favor of increasing the blocksize ==<br />
* More transactions per second<br />
* Off-chain solutions are not yet ready to take off the load from the main blockchain.<br />
<br />
== Unclear Arguments ==<br />
* Increased blocksize will leave space for extensions like Mastercoin, Counterparty, etc.<br />
** Neutral: Bitcoin competitors will have lower fees<br />
** Negative: Bitcoin full nodes are forced to use more resources that don't support Bitcoin<br />
* Small blocks eventually will require higher fees for fast confirmations.<br />
** Positive: It will no longer be cheap to spam transactions such as Satoshi Dice bets<br />
** Positive: Fees will not be zero. This is eventually a necessity in order to incentivize miners and secure the mining ecosystem<br />
** Negative: Bitcoin may look unattractive to new users with high fees<br />
** Negative: High fees may stop or reverse global adoption, investment, development, support and centralization{{clarification needed}}<br />
** Negative: Bitcoin users pay higher fees<br />
<br />
== Arguments in opposition to increasing the blocksize ==<br />
* A hard fork requires waiting for sufficient consensus.<br />
* Risk of catastrophic consensus failure<ref>https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html</ref>{{clarification needed}}<br />
* An emergency hard fork that can achieve consensus can be deployed on a short time period if needed.<ref>[https://www.reddit.com/r/Bitcoin/comments/392m43/mike_hearn_blocksize_debate_at_the_breaking_point/cs00wdd How to raise block size in a short time], Peter Todd, Reddit /r/Bitcoin, 9 June 2015</ref><br />
* Orphan rate amplification, more reorgs and double-spends due to slower propagation speeds.<br />
* European/American pools at more of a disadvantage compared to the Chinese pools{{why}}<br />
* "Congestion" concerns can be solved with mempool improvements including transaction eviction.<br />
* No amount of max block size would support all the world's future transactions on the main blockchain (various types of off-chain transactions are the only long-term solution)<br />
* Fast block propagation is either not clearly viable, or (eg, IBLT) creates centralised controls.<br />
* A low blocksize limit encourages higher transactions fees to incentivize miners ("let a fee market develop"). Counter-argument: [https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf A Transaction Fee Market Exists Without a Block Size Limit]<br />
<br />
=== Damage to decentralization ===<br />
* Larger blocks make full nodes more expensive to operate.<br />
* Therefore, larger blocks lead to less hashers running full nodes, which leads to centralized entities having more power, which makes Bitcoin require more trust, which weakens Bitcoins value proposition.<br />
* Bitcoin is only useful if it is decentralized because centralization requires trust. Bitcoins value proposition is trustlessness.<br />
* The larger the hash-rate a single miner controls, the more centralized Bitcoin becomes and the more trust using Bitcoin requires.<br />
* Running your own full node while mining rather than giving another entity the right to your hash-power decreases the hash-rate of large miners. Those who have hash-power are able to control their own hash power if and only if they run a full node.<br />
* Less individuals who control hash-power will run full nodes if running one becomes more expensive<ref>https://www.weusecoins.com/why-blocksize-limit-keeps-bitcoin-free-decentralized/</ref>.<br />
<br />
==Proposals==<br />
===BIP 100===<br />
Change block size limit based on miner votes, but don't leave the range (1MB, 32MB) without a softfork or hardfork respectively.<br />
===BIP 101===<br />
{{seealso|Bitcoin XT}}<br />
Increase to 8 MB after both January 11, 2016 has passed and 75% of miners are supporting. Double the limit every two years with the size increasing linearly within those two year intervals.<br />
===BIP 102===<br />
Increase to 2 MB on November 11, 2015.<br />
===BIP 103===<br />
Increase by 17.7% annually until 2063.<br />
<br />
== Entities positions ==<br />
Positions below are based on a suggested fixed block size increase to 20MiB. Positions against these larger blocks do not necessarily imply that they are against an increase in general, and may instead support a smaller and/or gradual increase.<br />
{| class="wikitable sortable"<br />
! Entity<br />
! Supports Larger Blocks<br />
! Supports Hard Fork<br />
|-<br />
| Bitcoinpaygate<br />
| {{No|No: "We do NOT support the blocksize increase"}}<ref>http://www.reddit.com/r/Bitcoin/comments/37y8wm/list_of_bitcoin_services_that_supportoppose/crqsnqp</ref><br />
|<br />
|-<br />
| Bitrated<br />
| {{No}}<br />"At this time, I oppose increasing the block size limit as per Gavin's proposal" - Nadav Ivgi (founder)<ref>https://twitter.com/shesek/status/605005384026177537</ref><br />
|<br />
|-<br />
| [[GreenAddress]]<br />
| {{No|No: "In our mind increasing the block size like this is just pushing the problem a little further at potentially unfixable costs."}}<ref>http://www.reddit.com/r/Bitcoin/comments/35anax/list_of_bitcoin_services_that_support_increasing/cr2mq84</ref><br />
|<br />
|-<br />
| [[MPEx]]<br />
| {{No}}<ref>http://log.bitcoin-assets.com//?date=07-01-2015#967332</ref><br />
|<br />
|-<br />
| [[Paymium]]<br />
| {{No|No: "<nowiki>[allow]</nowiki> a sane transaction fee market to emerge, by letting the blocks actually fill-up."}} - CTO David Francois<ref>http://fr.anco.is/2015/gavineries/</ref><br />
| <br />
|-<br />
| Ethereum<br /><br />
| {{Neutral|Neutral: "If <nowiki>[the niche of digital gold]</nowiki> is what Bitcoin users want, then they should keep the limit, and perhaps even decrease it. But if Bitcoin users want to be a payment system, then up it must go."}} - Vitalik Buterin (founder)<ref>http://www.reddit.com/r/ethereum/comments/380q61/i_know_this_may_not_directly_be_ethereum_related/crrofl6</ref><br />
|<br />
|-<br />
| [[F2Pool]]<br />
| {{Neutral|Neutral: "We do support bigger blocks and sooner rather than later. But we cannot handle 20 MB blocks right now. ... I think we can accept 5MB block at most."}}<ref>http://sourceforge.net/p/bitcoin/mailman/message/34157036/],[http://sourceforge.net/p/bitcoin/mailman/message/34158911/</ref><br />
|<br />
|-<br />
| [[Armory]]<br />
| {{Yes}}<br />"This *is* urgent and needs to be handled right now, and I believe Gavin<br />
has the best approach to this." - CEO Alan Reiner<ref>http://sourceforge.net/p/bitcoin/mailman/message/34093337/</ref><br />
|<br />
|-<br />
| BitcoinReminder<br />
| {{Yes|Yes: "BitcoinReminder.com also supports 20MB blocks (or even more?"}}<ref>http://www.reddit.com/r/Bitcoin/comments/37y8wm/list_of_bitcoin_services_that_supportoppose/crs9ytd</ref><br />
|<br />
|-<br />
| BitHours<br />
| {{Yes|Yes: "We support @gavinandresen and his proposal for 20mb blocks"}}<ref>https://twitter.com/bithours/status/605131647747358721</ref><br />
|<br />
|-<br />
| [[BitPay]]<br />
| {{Yes}}<br />"Agreed (but optimistic this will be the last and only time block size needs to increase)" - CEO Stephen Pair<ref>https://twitter.com/spair/status/595341090317799424</ref><br />
| {{Yes|Yes: "In summary, we believe BIP 101 will safeguard Bitcoin’s decentralized nature while providing a reliable, immediate path toward greater network throughput, and we would like to express our support for merging BIP 101 into Bitcoin Core."}} - Stephen Pair<ref>https://medium.com/@spair/increasing-the-block-size-limit-85ff236fc516</ref><br />
|-<br />
| Bittiraha.fi<br />
| {{Yes|Yes: "We are supporting increasing #Bitcoin max block size to 20MB."}}<ref>https://twitter.com/Bittirahafi/status/596682373028311040</ref><br />"I'm strongly in favor of the block size cap increase to 20MB." - CEO Henry Brade<ref>https://twitter.com/Technom4ge/status/596334370803326978</ref><br />
| {{Yes}}<br />"And I'm in favor of releasing a version with this change even with opposition." - CEO Henry Brade<ref>https://twitter.com/Technom4ge/status/596334370803326978</ref><br />
|-<br />
| [[Blockchain.info]]<br />
|{{Yes}}<br />"It is time to increase the block size. Agree with @gavinandresen" - CEO Peter Smith<ref>https://twitter.com/OneMorePeter/status/595676380320407553</ref><br />"Scaling #bitcoin is a big deal. Increase the block size." - Nic Cary<ref>https://twitter.com/niccary/status/595707211994763264</ref><br />
|<br />
|-<br />
| [[Blocktrail]]<br />
|{{Yes}}<br />"We'd love to see BIP101 with 4mb start, alternatively BIP100 with something to deal with the 21% attack could be good too."<ref>https://blog.blocktrail.com/2015/08/miners-block-size-vote-explained/</ref><br /><br />
|<br />
|-<br />
| Breadwallet<br />
| {{Yes}}<br />"[...] in support of the Gavin's 20Mb block proposal." - CEO Aaron Voisine<ref>http://sourceforge.net/p/bitcoin/mailman/message/34096857/</ref><br />
|<br />
|-<br />
| [[BTC Guild]]<br />
<br />
| {{Yes}}<br />"Needs to happen, but needs future expansion built in at a reasonable rate." - Eleuthria<ref>https://www.reddit.com/r/Bitcoin/comments/370rko/21_inc_engineer_everyone_assumes_humans_will_be/crjfnpg?context=3</ref><br />
|<br />
|-<br />
| BX.in.th<br />
| {{Yes|Yes: "<nowiki>http://BX.in.th</nowiki> will support the 20MB block size"}}<ref>https://twitter.com/BitcoinThai/status/605022509101023232</ref><br />
| <br />
|- <br />
| [[Coinbase (business)|CoinBase]]<br />
| {{Yes|Yes: "Coinbase supports increasing the maximum block size"}}<ref>https://twitter.com/coinbase/status/595741967759335426</ref><br />"Why we should increase the block size" - CEO Brian Armstrong<ref>https://twitter.com/brian_armstrong/status/595453245884997634</ref><br />
| {{Yes|Yes: "5/ hard forks probably shouldn't happen frequently, but periodically they are an elegant solution that helps bitcoin keep growing"}} - CEO Brian Armstrong<ref>https://twitter.com/brian_armstrong/status/633309671994998784</ref><br />
|- <br />
| [[Dr. Adam Back (individual)|Dr. Adam Back]]<br />
| {{Yes|Yes: "For the record I am not aware of a single person who has said they do not agree with scaling Bitcoin. Changing a constant is not the hard-part. The hard part is validating a plan and the other factors that go into it. It's not a free choice it is a security/scalability tradeoff. No one will thank us if we "scale" bitcoin but break it in hard to recover ways at the same time."}} <ref>https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html</ref><br />
| {{No}}<br />"I strongly urge that we return to the existing collaborative constructive review process that has been used for the last 4 years which is a consensus by design to prevent one rogue person from inserting a backdoor, or lobbying for a favoured change on behalf of a special interest group, or working for bad actor" - Dr. Adam Back<ref>https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html</ref><br />
|<br />
|-<br />
| Kryptoradio<br />
| {{Yes}}<br />"#Kryptoradio dev @zouppen supports 20MB block size in #bitcoin." - Joel Lehtonen<ref>https://twitter.com/koodilehto/status/596675967667568641</ref><br />
|<br />
|- <br />
| [[OKCoin]]<br />
| {{Yes|Yes: "OKCoin's tech team believes it's the right decision"}}<ref>https://twitter.com/okcoinbtc/status/598412795240009728</ref><br />
|<br />
|-<br />
| [[Third Key Solutions]]<br />
| {{Yes}}<br />"Gavin is right. The time to increase the block size limit is before transaction processing shows congestion problems." - CTO Andreas Antonopoulos<ref>https://twitter.com/aantonop/status/595601619581964289</ref><br />
|<br />
|-<br />
| [[Xapo]]<br />
| {{Yes|Yes: "One meg is not enough: Xapo supports increasing the maximum block size"}} - CEO Wences Casares<ref>https://twitter.com/wences/status/595768917907402752</ref><br />
|<br />
|}<br />
<br />
==References==<br />
<references/><br />
[[Category:2015 events]]</div>Lapp0https://en.bitcoin.it/w/index.php?title=Talk:Block_size_limit_controversy&diff=58282Talk:Block size limit controversy2015-08-12T05:21:15Z<p>Lapp0: </p>
<hr />
<div>I think the article needs a revision from the ground up since I think there is consensus that the limit should be increased, it is just unclear when to do that and by how much. Also, the "A hard fork requires waiting for sufficient consensus." argument is actually very unclear because there is no measure of consensus short of the longest blockchain. Bitcoin core dev consensus is arbitrary and also represents a centralisation. ---Unsigned comment by [[User:Chaosgrid]]<br />
<br />
: (1) I agree there is widespread consensus that the limit should eventually be increased. (2) I don't think the inability to independently measure consensus is a barrier to determining when a proposal does or does not have consensus. When there are several important members of our community objecting to a proposal, it is safe to say that consensus has not been obtained. ---[[User:Harding|Harding]] ([[User talk:Harding|talk]]) 23:26, 10 August 2015 (UTC)<br />
<br />
: I think the positions can still be split, but not between never increase and increase now as it appears to be split at the moment. A more representative question to debate would be "should the blocksize be increased in the near future". Near future may be defined as the next year and a half. Longest blockchain isn't guaranteed to be the consensus blockchain and the consensus required isn't between core devs, rather Bitcoin users. I think saying "sufficient consensus" is fine because there isn't a line between damage happening due to insufficient consensus and no damage happening. There are degrees of damage, with a 50% split being the worst and one small transaction being reversed due to someones broken consensus being the least bad, and 100% agreement being the perfect result. --[[User:Lapp0|Lapp0]] ([[User talk:Lapp0|talk]]) 05:05, 12 August 2015 (UTC)<br />
<br />
<br />
I removed the congestion and failing client arguments. The failing argument in particular has nothing to do with block size and everything to do with spam prevention. The congestion argument doesn't apply when replace by fee and child pays for parent exist. I left the high fee argument because it is the out of solving these two argued problems that were removed. --[[User:Lapp0|Lapp0]] ([[User talk:Lapp0|talk]]) 05:08, 12 August 2015 (UTC)<br />
<br />
I also merged your feerate argument with its section in undecided arguments since it is already covered there partially, let me know if this isn't satisfactory. --[[User:Lapp0|Lapp0]] ([[User talk:Lapp0|talk]]) 05:21, 12 August 2015 (UTC)</div>Lapp0https://en.bitcoin.it/w/index.php?title=Block_size_limit_controversy&diff=58281Block size limit controversy2015-08-12T05:19:29Z<p>Lapp0: Moved fee cost to unclear arguments. Centralization argument needs clarification.</p>
<hr />
<div>{{current}}{{see also|Scalability FAQ}}<br />
[[Block]]s are limited to 1MB in size. Miners can mine blocks up to the 1MB fixed limit, but any block larger than 1MB is invalid. This limit cannot be modified without a hard fork. To prevent Bitcoin from temporarily or permanently splitting into separate payment networks ("altcoins"), hard forks require adoption by nearly all [[Full node#Economic_strength|economically active]] full nodes.<br />
<br />
== Arguments in favor of increasing the blocksize ==<br />
* More transactions per second<br />
* Off-chain solutions are not yet ready to take off the load from the main blockchain.<br />
<br />
== Unclear Arguments ==<br />
* Increased blocksize will leave space for extensions like Mastercoin, Counterparty, etc.<br />
** Neutral: Bitcoin competitors will have lower fees<br />
** Negative: Bitcoin full nodes are forced to use more resources that don't support Bitcoin<br />
* Small blocks eventually will require higher fees for fast confirmations.<br />
** Positive: It will no longer be cheap to spam transactions such as Satoshi Dice bets<br />
** Positive: Fees will not be zero. This is eventually a necessity in order to incentivize miners and secure the mining ecosystem<br />
** Negative: Bitcoin may look unattractive to new users with high fees<br />
** Negative: High fees may stop or reverse global adoption, investment, development, support and centralization{{clarification needed}}<br />
** Negative: Bitcoin users pay higher fees<br />
<br />
== Arguments in opposition to increasing the blocksize ==<br />
* A hard fork requires waiting for sufficient consensus.<br />
* Risk of catastrophic consensus failure<ref>https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html</ref>{{clarification needed}}<br />
* An emergency hard fork that can achieve consensus can be deployed on a short time period if needed.<ref>[https://www.reddit.com/r/Bitcoin/comments/392m43/mike_hearn_blocksize_debate_at_the_breaking_point/cs00wdd How to raise block size in a short time], Peter Todd, Reddit /r/Bitcoin, 9 June 2015</ref><br />
* Orphan rate amplification, more reorgs and double-spends due to slower propagation speeds.<br />
* European/American pools at more of a disadvantage compared to the Chinese pools{{why}}<br />
* "Congestion" concerns can be solved with mempool improvements including transaction eviction.<br />
* No amount of max block size would support all the world's future transactions on the main blockchain (various types of off-chain transactions are the only long-term solution)<br />
* Fast block propagation is either not clearly viable, or (eg, IBLT) creates centralised controls.<br />
* A low blocksize limit encourages higher transactions fees to incentivize miners ("let a fee market develop")<br />
<br />
=== Damage to decentralization ===<br />
* Larger blocks make full nodes more expensive to operate.<br />
* Therefore, larger blocks lead to less hashers running full nodes, which leads to centralized entities having more power, which makes Bitcoin require more trust, which weakens Bitcoins value proposition.<br />
* Bitcoin is only useful if it is decentralized because centralization requires trust. Bitcoins value proposition is trustlessness.<br />
* The larger the hash-rate a single miner controls, the more centralized Bitcoin becomes and the more trust using Bitcoin requires.<br />
* Running your own full node while mining rather than giving another entity the right to your hash-power decreases the hash-rate of large miners. Those who have hash-power are able to control their own hash power if and only if they run a full node.<br />
* Less individuals who control hash-power will run full nodes if running one becomes more expensive<ref>https://www.weusecoins.com/why-blocksize-limit-keeps-bitcoin-free-decentralized/</ref>.<br />
<br />
== Entities positions ==<br />
Positions below are based on a suggested fixed block size increase to 20MiB. Positions against these larger blocks do not necessarily imply that they are against an increase in general, and may instead support a smaller and/or gradual increase.<br />
{| class="wikitable sortable"<br />
! Entity<br />
! Supports Larger Blocks<br />
! Supports Hard Fork<br />
|-<br />
| Bitcoinpaygate<br />
| {{No|No: "We do NOT support the blocksize increase"}}<ref>http://www.reddit.com/r/Bitcoin/comments/37y8wm/list_of_bitcoin_services_that_supportoppose/crqsnqp</ref><br />
|<br />
|-<br />
| Bitrated<br />
| {{No}}<br />"At this time, I oppose increasing the block size limit as per Gavin's proposal" - Nadav Ivgi (founder)<ref>https://twitter.com/shesek/status/605005384026177537</ref><br />
|<br />
|-<br />
| [[GreenAddress]]<br />
| {{No|No: "In our mind increasing the block size like this is just pushing the problem a little further at potentially unfixable costs."}}<ref>http://www.reddit.com/r/Bitcoin/comments/35anax/list_of_bitcoin_services_that_support_increasing/cr2mq84</ref><br />
|<br />
|-<br />
| [[MPEx]]<br />
| {{No}}<ref>http://log.bitcoin-assets.com//?date=07-01-2015#967332</ref><br />
|<br />
|-<br />
| [[Paymium]]<br />
| {{No|No: "<nowiki>[allow]</nowiki> a sane transaction fee market to emerge, by letting the blocks actually fill-up."}} - CTO David Francois<ref>http://fr.anco.is/2015/gavineries/</ref><br />
| <br />
|-<br />
| Ethereum<br /><br />
| {{Neutral|Neutral: "If <nowiki>[the niche of digital gold]</nowiki> is what Bitcoin users want, then they should keep the limit, and perhaps even decrease it. But if Bitcoin users want to be a payment system, then up it must go."}} - Vitalik Buterin (founder)<ref>http://www.reddit.com/r/ethereum/comments/380q61/i_know_this_may_not_directly_be_ethereum_related/crrofl6</ref><br />
|<br />
|-<br />
| [[F2Pool]]<br />
| {{Neutral|Neutral: "We do support bigger blocks and sooner rather than later. But we cannot handle 20 MB blocks right now. ... I think we can accept 5MB block at most."}}<ref>http://sourceforge.net/p/bitcoin/mailman/message/34157036/],[http://sourceforge.net/p/bitcoin/mailman/message/34158911/</ref><br />
|<br />
|-<br />
| [[Armory]]<br />
| {{Yes}}<br />"This *is* urgent and needs to be handled right now, and I believe Gavin<br />
has the best approach to this." - CEO Alan Reiner<ref>http://sourceforge.net/p/bitcoin/mailman/message/34093337/</ref><br />
|<br />
|-<br />
| BitcoinReminder<br />
| {{Yes|Yes: "BitcoinReminder.com also supports 20MB blocks (or even more?"}}<ref>http://www.reddit.com/r/Bitcoin/comments/37y8wm/list_of_bitcoin_services_that_supportoppose/crs9ytd</ref><br />
|<br />
|-<br />
| BitHours<br />
| {{Yes|Yes: "We support @gavinandresen and his proposal for 20mb blocks"}}<ref>https://twitter.com/bithours/status/605131647747358721</ref><br />
|<br />
|-<br />
| [[BitPay]]<br />
| {{Yes}}<br />"Agreed (but optimistic this will be the last and only time block size needs to increase)" - CEO Stephen Pair<ref>https://twitter.com/spair/status/595341090317799424</ref><br />
| <br />
|-<br />
| Bittiraha.fi<br />
| {{Yes|Yes: "We are supporting increasing #Bitcoin max block size to 20MB."}}<ref>https://twitter.com/Bittirahafi/status/596682373028311040</ref><br />"I'm strongly in favor of the block size cap increase to 20MB." - CEO Henry Brade<ref>https://twitter.com/Technom4ge/status/596334370803326978</ref><br />
| {{Yes}}<br />"And I'm in favor of releasing a version with this change even with opposition." - CEO Henry Brade<ref>https://twitter.com/Technom4ge/status/596334370803326978</ref><br />
|-<br />
| [[Blockchain.info]]<br />
|{{Yes}}<br />"It is time to increase the block size. Agree with @gavinandresen" - CEO Peter Smith<ref>https://twitter.com/OneMorePeter/status/595676380320407553</ref><br />"Scaling #bitcoin is a big deal. Increase the block size." - Nic Cary<ref>https://twitter.com/niccary/status/595707211994763264</ref><br />
|<br />
|-<br />
| Breadwallet<br />
| {{Yes}}<br />"[...] in support of the Gavin's 20Mb block proposal." - CEO Aaron Voisine<ref>http://sourceforge.net/p/bitcoin/mailman/message/34096857/</ref><br />
|<br />
|-<br />
| [[BTC Guild]]<br />
| {{Yes}}<br />"Needs to happen, but needs future expansion built in at a reasonable rate." - Eleuthria<ref>https://www.reddit.com/r/Bitcoin/comments/370rko/21_inc_engineer_everyone_assumes_humans_will_be/crjfnpg?context=3</ref><br />
|<br />
|-<br />
| BX.in.th<br />
| {{Yes|Yes: "<nowiki>http://BX.in.th</nowiki> will support the 20MB block size"}}<ref>https://twitter.com/BitcoinThai/status/605022509101023232</ref><br />
| <br />
|- <br />
| [[Coinbase (business)|CoinBase]]<br />
| {{Yes|Yes: "Coinbase supports increasing the maximum block size"}}<ref>https://twitter.com/coinbase/status/595741967759335426</ref><br />"Why we should increase the block size" - CEO Brian Armstrong<ref>https://twitter.com/brian_armstrong/status/595453245884997634</ref><br />
|<br />
|- <br />
| [[Dr. Adam Back (individual)|Dr. Adam Back]]<br />
| {{Yes|Yes: "For the record I am not aware of a single person who has said they do not agree with scaling Bitcoin. Changing a constant is not the hard-part. The hard part is validating a plan and the other factors that go into it. It's not a free choice it is a security/scalability tradeoff. No one will thank us if we "scale" bitcoin but break it in hard to recover ways at the same time."}} <ref>https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html</ref><br />
| {{No}}<br />"I strongly urge that we return to the existing collaborative constructive review process that has been used for the last 4 years which is a consensus by design to prevent one rogue person from inserting a backdoor, or lobbying for a favoured change on behalf of a special interest group, or working for bad actor" - Dr. Adam Back<ref>https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html</ref><br />
|<br />
|-<br />
| Kryptoradio<br />
| {{Yes}}<br />"#Kryptoradio dev @zouppen supports 20MB block size in #bitcoin." - Joel Lehtonen<ref>https://twitter.com/koodilehto/status/596675967667568641</ref><br />
|<br />
|- <br />
| [[OKCoin]]<br />
| {{Yes|Yes: "OKCoin's tech team believes it's the right decision"}}<ref>https://twitter.com/okcoinbtc/status/598412795240009728</ref><br />
|<br />
|-<br />
| [[Third Key Solutions]]<br />
| {{Yes}}<br />"Gavin is right. The time to increase the block size limit is before transaction processing shows congestion problems." - CTO Andreas Antonopoulos<ref>https://twitter.com/aantonop/status/595601619581964289</ref><br />
|<br />
|-<br />
| [[Xapo]]<br />
| {{Yes|Yes: "One meg is not enough: Xapo supports increasing the maximum block size"}} - CEO Wences Casares<ref>https://twitter.com/wences/status/595768917907402752</ref><br />
|<br />
|}<br />
[[Category:2015 events]]</div>Lapp0https://en.bitcoin.it/w/index.php?title=Talk:Block_size_limit_controversy&diff=58280Talk:Block size limit controversy2015-08-12T05:08:03Z<p>Lapp0: </p>
<hr />
<div>I think the article needs a revision from the ground up since I think there is consensus that the limit should be increased, it is just unclear when to do that and by how much. Also, the "A hard fork requires waiting for sufficient consensus." argument is actually very unclear because there is no measure of consensus short of the longest blockchain. Bitcoin core dev consensus is arbitrary and also represents a centralisation. ---Unsigned comment by [[User:Chaosgrid]]<br />
<br />
: (1) I agree there is widespread consensus that the limit should eventually be increased. (2) I don't think the inability to independently measure consensus is a barrier to determining when a proposal does or does not have consensus. When there are several important members of our community objecting to a proposal, it is safe to say that consensus has not been obtained. ---[[User:Harding|Harding]] ([[User talk:Harding|talk]]) 23:26, 10 August 2015 (UTC)<br />
<br />
: I think the positions can still be split, but not between never increase and increase now as it appears to be split at the moment. A more representative question to debate would be "should the blocksize be increased in the near future". Near future may be defined as the next year and a half. Longest blockchain isn't guaranteed to be the consensus blockchain and the consensus required isn't between core devs, rather Bitcoin users.<br />
: I think saying "sufficient consensus" is fine because there isn't a line between damage happening due to insufficient consensus and no damage happening. There are degrees of damage, with a 50% split being the worst and one small transaction being reversed due to someones broken consensus being the least bad, and 100% agreement being the perfect result. --[[User:Lapp0|Lapp0]] ([[User talk:Lapp0|talk]]) 05:05, 12 August 2015 (UTC)<br />
<br />
<br />
I removed the congestion and failing client arguments. The failing argument in particular has nothing to do with block size and everything to do with spam prevention. The congestion argument doesn't apply when replace by fee and child pays for parent exist. I left the high fee argument because it is the out of solving these two argued problems that were removed. --[[User:Lapp0|Lapp0]] ([[User talk:Lapp0|talk]]) 05:08, 12 August 2015 (UTC)</div>Lapp0https://en.bitcoin.it/w/index.php?title=Talk:Block_size_limit_controversy&diff=58279Talk:Block size limit controversy2015-08-12T05:05:28Z<p>Lapp0: forgot signature</p>
<hr />
<div>I think the article needs a revision from the ground up since I think there is consensus that the limit should be increased, it is just unclear when to do that and by how much. Also, the "A hard fork requires waiting for sufficient consensus." argument is actually very unclear because there is no measure of consensus short of the longest blockchain. Bitcoin core dev consensus is arbitrary and also represents a centralisation. ---Unsigned comment by [[User:Chaosgrid]]<br />
<br />
: (1) I agree there is widespread consensus that the limit should eventually be increased. (2) I don't think the inability to independently measure consensus is a barrier to determining when a proposal does or does not have consensus. When there are several important members of our community objecting to a proposal, it is safe to say that consensus has not been obtained. ---[[User:Harding|Harding]] ([[User talk:Harding|talk]]) 23:26, 10 August 2015 (UTC)<br />
<br />
: I think the positions can still be split, but not between never increase and increase now as it appears to be split at the moment. A more representative question to debate would be "should the blocksize be increased in the near future". Near future may be defined as the next year and a half. Longest blockchain isn't guaranteed to be the consensus blockchain and the consensus required isn't between core devs, rather Bitcoin users.<br />
: I think saying "sufficient consensus" is fine because there isn't a line between damage happening due to insufficient consensus and no damage happening. There are degrees of damage, with a 50% split being the worst and one small transaction being reversed due to someones broken consensus being the least bad, and 100% agreement being the perfect result. --[[User:Lapp0|Lapp0]] ([[User talk:Lapp0|talk]]) 05:05, 12 August 2015 (UTC)</div>Lapp0https://en.bitcoin.it/w/index.php?title=Talk:Block_size_limit_controversy&diff=58278Talk:Block size limit controversy2015-08-12T05:04:55Z<p>Lapp0: </p>
<hr />
<div>I think the article needs a revision from the ground up since I think there is consensus that the limit should be increased, it is just unclear when to do that and by how much. Also, the "A hard fork requires waiting for sufficient consensus." argument is actually very unclear because there is no measure of consensus short of the longest blockchain. Bitcoin core dev consensus is arbitrary and also represents a centralisation. ---Unsigned comment by [[User:Chaosgrid]]<br />
<br />
: (1) I agree there is widespread consensus that the limit should eventually be increased. (2) I don't think the inability to independently measure consensus is a barrier to determining when a proposal does or does not have consensus. When there are several important members of our community objecting to a proposal, it is safe to say that consensus has not been obtained. ---[[User:Harding|Harding]] ([[User talk:Harding|talk]]) 23:26, 10 August 2015 (UTC)<br />
<br />
: I think the positions can still be split, but not between never increase and increase now as it appears to be split at the moment. A more representative question to debate would be "should the blocksize be increased in the near future". Near future may be defined as the next year and a half. Longest blockchain isn't guaranteed to be the consensus blockchain and the consensus required isn't between core devs, rather Bitcoin users.<br />
: I think saying "sufficient consensus" is fine because there isn't a line between damage happening due to insufficient consensus and no damage happening. There are degrees of damage, with a 50% split being the worst and one small transaction being reversed due to someones broken consensus being the least bad, and 100% agreement being the perfect result.</div>Lapp0https://en.bitcoin.it/w/index.php?title=Block_size_limit_controversy&diff=58277Block size limit controversy2015-08-12T04:58:45Z<p>Lapp0: "Congestion" is a myth. A sufficient fee, as always, will get your transaction confirmed. Higher fees is a valid complaint, but "congestion" is not. Larger blocks cannot prevent the mempool from becoming too large and causing a client to crash.</p>
<hr />
<div>{{current}}{{see also|Scalability FAQ}}<br />
[[Block]]s are limited to 1MB in size. Miners can mine blocks up to the 1MB fixed limit, but any block larger than 1MB is invalid. This limit cannot be modified without a hard fork. To prevent Bitcoin from temporarily or permanently splitting into separate payment networks ("altcoins"), hard forks require adoption by nearly all [[Full node#Economic_strength|economically active]] full nodes.<br />
<br />
== Arguments in favor of increasing the blocksize ==<br />
* More transactions per second<br />
* Rising fees due to the low blocksize limit will make bitcoin unattractive and will stop or even reverse global adoption, in turn leading to less interest, less investment, less development, less support and consequently also more centralisation and an unstable network.<br />
* Off-chain solutions are not yet ready to take off the load from the main blockchain.<br />
<br />
== Unclear Arguments ==<br />
* Increased blocksize will leave space for extensions like Mastercoin, Counterparty, etc.<br />
** Neutral: Bitcoin competitors will have lower fees<br />
** Negative: Bitcoin full nodes are forced to use more resources that don't support Bitcoin<br />
* Faster confirmation times with lower fees required<br />
** Positive: Bitcoin users pay lower fees<br />
** Negative: It will continue to be cheap to spam transactions such as Satoshi Dice bets<br />
** Negative: Fees cannot be zero eventually in order to secure the mining ecosystem<br />
<br />
== Arguments in opposition to increasing the blocksize ==<br />
* A hard fork requires waiting for sufficient consensus.<br />
* Risk of catastrophic consensus failure<ref>https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html</ref>{{clarification needed}}<br />
* An emergency hard fork that can achieve consensus can be deployed on a short time period if needed.<ref>[https://www.reddit.com/r/Bitcoin/comments/392m43/mike_hearn_blocksize_debate_at_the_breaking_point/cs00wdd How to raise block size in a short time], Peter Todd, Reddit /r/Bitcoin, 9 June 2015</ref><br />
* Orphan rate amplification, more reorgs and double-spends due to slower propagation speeds.<br />
* European/American pools at more of a disadvantage compared to the Chinese pools{{why}}<br />
* "Congestion" concerns can be solved with mempool improvements including transaction eviction.<br />
* No amount of max block size would support all the world's future transactions on the main blockchain (various types of off-chain transactions are the only long-term solution)<br />
* Fast block propagation is either not clearly viable, or (eg, IBLT) creates centralised controls.<br />
* A low blocksize limit encourages higher transactions fees to incentivize miners ("let a fee market develop")<br />
<br />
=== Damage to decentralization ===<br />
* Larger blocks make full nodes more expensive to operate.<br />
* Therefore, larger blocks lead to less hashers running full nodes, which leads to centralized entities having more power, which makes Bitcoin require more trust, which weakens Bitcoins value proposition.<br />
* Bitcoin is only useful if it is decentralized because centralization requires trust. Bitcoins value proposition is trustlessness.<br />
* The larger the hash-rate a single miner controls, the more centralized Bitcoin becomes and the more trust using Bitcoin requires.<br />
* Running your own full node while mining rather than giving another entity the right to your hash-power decreases the hash-rate of large miners. Those who have hash-power are able to control their own hash power if and only if they run a full node.<br />
* Less individuals who control hash-power will run full nodes if running one becomes more expensive<ref>https://www.weusecoins.com/why-blocksize-limit-keeps-bitcoin-free-decentralized/</ref>.<br />
<br />
== Entities positions ==<br />
Positions below are based on a suggested fixed block size increase to 20MiB. Positions against these larger blocks do not necessarily imply that they are against an increase in general, and may instead support a smaller and/or gradual increase.<br />
{| class="wikitable sortable"<br />
! Entity<br />
! Supports Larger Blocks<br />
! Supports Hard Fork<br />
|-<br />
| Bitcoinpaygate<br />
| {{No|No: "We do NOT support the blocksize increase"}}<ref>http://www.reddit.com/r/Bitcoin/comments/37y8wm/list_of_bitcoin_services_that_supportoppose/crqsnqp</ref><br />
|<br />
|-<br />
| Bitrated<br />
| {{No}}<br />"At this time, I oppose increasing the block size limit as per Gavin's proposal" - Nadav Ivgi (founder)<ref>https://twitter.com/shesek/status/605005384026177537</ref><br />
|<br />
|-<br />
| [[GreenAddress]]<br />
| {{No|No: "In our mind increasing the block size like this is just pushing the problem a little further at potentially unfixable costs."}}<ref>http://www.reddit.com/r/Bitcoin/comments/35anax/list_of_bitcoin_services_that_support_increasing/cr2mq84</ref><br />
|<br />
|-<br />
| [[MPEx]]<br />
| {{No}}<ref>http://log.bitcoin-assets.com//?date=07-01-2015#967332</ref><br />
|<br />
|-<br />
| [[Paymium]]<br />
| {{No|No: "<nowiki>[allow]</nowiki> a sane transaction fee market to emerge, by letting the blocks actually fill-up."}} - CTO David Francois<ref>http://fr.anco.is/2015/gavineries/</ref><br />
| <br />
|-<br />
| Ethereum<br /><br />
| {{Neutral|Neutral: "If <nowiki>[the niche of digital gold]</nowiki> is what Bitcoin users want, then they should keep the limit, and perhaps even decrease it. But if Bitcoin users want to be a payment system, then up it must go."}} - Vitalik Buterin (founder)<ref>http://www.reddit.com/r/ethereum/comments/380q61/i_know_this_may_not_directly_be_ethereum_related/crrofl6</ref><br />
|<br />
|-<br />
| [[F2Pool]]<br />
| {{Neutral|Neutral: "We do support bigger blocks and sooner rather than later. But we cannot handle 20 MB blocks right now. ... I think we can accept 5MB block at most."}}<ref>http://sourceforge.net/p/bitcoin/mailman/message/34157036/],[http://sourceforge.net/p/bitcoin/mailman/message/34158911/</ref><br />
|<br />
|-<br />
| [[Armory]]<br />
| {{Yes}}<br />"This *is* urgent and needs to be handled right now, and I believe Gavin<br />
has the best approach to this." - CEO Alan Reiner<ref>http://sourceforge.net/p/bitcoin/mailman/message/34093337/</ref><br />
|<br />
|-<br />
| BitcoinReminder<br />
| {{Yes|Yes: "BitcoinReminder.com also supports 20MB blocks (or even more?"}}<ref>http://www.reddit.com/r/Bitcoin/comments/37y8wm/list_of_bitcoin_services_that_supportoppose/crs9ytd</ref><br />
|<br />
|-<br />
| BitHours<br />
| {{Yes|Yes: "We support @gavinandresen and his proposal for 20mb blocks"}}<ref>https://twitter.com/bithours/status/605131647747358721</ref><br />
|<br />
|-<br />
| [[BitPay]]<br />
| {{Yes}}<br />"Agreed (but optimistic this will be the last and only time block size needs to increase)" - CEO Stephen Pair<ref>https://twitter.com/spair/status/595341090317799424</ref><br />
| <br />
|-<br />
| Bittiraha.fi<br />
| {{Yes|Yes: "We are supporting increasing #Bitcoin max block size to 20MB."}}<ref>https://twitter.com/Bittirahafi/status/596682373028311040</ref><br />"I'm strongly in favor of the block size cap increase to 20MB." - CEO Henry Brade<ref>https://twitter.com/Technom4ge/status/596334370803326978</ref><br />
| {{Yes}}<br />"And I'm in favor of releasing a version with this change even with opposition." - CEO Henry Brade<ref>https://twitter.com/Technom4ge/status/596334370803326978</ref><br />
|-<br />
| [[Blockchain.info]]<br />
|{{Yes}}<br />"It is time to increase the block size. Agree with @gavinandresen" - CEO Peter Smith<ref>https://twitter.com/OneMorePeter/status/595676380320407553</ref><br />"Scaling #bitcoin is a big deal. Increase the block size." - Nic Cary<ref>https://twitter.com/niccary/status/595707211994763264</ref><br />
|<br />
|-<br />
| Breadwallet<br />
| {{Yes}}<br />"[...] in support of the Gavin's 20Mb block proposal." - CEO Aaron Voisine<ref>http://sourceforge.net/p/bitcoin/mailman/message/34096857/</ref><br />
|<br />
|-<br />
| [[BTC Guild]]<br />
| {{Yes}}<br />"Needs to happen, but needs future expansion built in at a reasonable rate." - Eleuthria<ref>https://www.reddit.com/r/Bitcoin/comments/370rko/21_inc_engineer_everyone_assumes_humans_will_be/crjfnpg?context=3</ref><br />
|<br />
|-<br />
| BX.in.th<br />
| {{Yes|Yes: "<nowiki>http://BX.in.th</nowiki> will support the 20MB block size"}}<ref>https://twitter.com/BitcoinThai/status/605022509101023232</ref><br />
| <br />
|- <br />
| [[Coinbase (business)|CoinBase]]<br />
| {{Yes|Yes: "Coinbase supports increasing the maximum block size"}}<ref>https://twitter.com/coinbase/status/595741967759335426</ref><br />"Why we should increase the block size" - CEO Brian Armstrong<ref>https://twitter.com/brian_armstrong/status/595453245884997634</ref><br />
|<br />
|- <br />
| [[Dr. Adam Back (individual)|Dr. Adam Back]]<br />
| {{Yes|Yes: "For the record I am not aware of a single person who has said they do not agree with scaling Bitcoin. Changing a constant is not the hard-part. The hard part is validating a plan and the other factors that go into it. It's not a free choice it is a security/scalability tradeoff. No one will thank us if we "scale" bitcoin but break it in hard to recover ways at the same time."}} <ref>https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html</ref><br />
| {{No}}<br />"I strongly urge that we return to the existing collaborative constructive review process that has been used for the last 4 years which is a consensus by design to prevent one rogue person from inserting a backdoor, or lobbying for a favoured change on behalf of a special interest group, or working for bad actor" - Dr. Adam Back<ref>https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html</ref><br />
|<br />
|-<br />
| Kryptoradio<br />
| {{Yes}}<br />"#Kryptoradio dev @zouppen supports 20MB block size in #bitcoin." - Joel Lehtonen<ref>https://twitter.com/koodilehto/status/596675967667568641</ref><br />
|<br />
|- <br />
| [[OKCoin]]<br />
| {{Yes|Yes: "OKCoin's tech team believes it's the right decision"}}<ref>https://twitter.com/okcoinbtc/status/598412795240009728</ref><br />
|<br />
|-<br />
| [[Third Key Solutions]]<br />
| {{Yes}}<br />"Gavin is right. The time to increase the block size limit is before transaction processing shows congestion problems." - CTO Andreas Antonopoulos<ref>https://twitter.com/aantonop/status/595601619581964289</ref><br />
|<br />
|-<br />
| [[Xapo]]<br />
| {{Yes|Yes: "One meg is not enough: Xapo supports increasing the maximum block size"}} - CEO Wences Casares<ref>https://twitter.com/wences/status/595768917907402752</ref><br />
|<br />
|}<br />
[[Category:2015 events]]</div>Lapp0https://en.bitcoin.it/w/index.php?title=Scalability&diff=57432Scalability2015-07-10T07:37:31Z<p>Lapp0: removed run on sentence, expanded on claim of low cost full nodes, removed mention of time improvements since security shouldn't be discussed in terms of maybe working in the future unless it is explicitly stated as "maybe it will work in the future".</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. Otherwise our result is a few, or just one, centralized parties that control the blockchain and are able to reverse or censor transactions, evidenced by the network previously beginning to converge to centralization to under much much smaller load. Others argue that under any realistic maximum usage scenario, like in the case of 24 GB blocks, full node requirements would not be so great. This is argued in spite of the fact that the processor requirements are 40 i7s<ref>http://ark.intel.com/products/53469</ref> costing $6000, one petabyte worth of disk space per year costing $30,000<ref>http://www.amazon.com/Seagate-Desktop-3-5-Inch-Internal-ST4000DM000/dp/B00B99JU4S</ref>, and $50,000 yearly for 2PB of bandwidth (that is with the generous assumption that upload costs are the same as download costs)<ref>http://business.financialpost.com/fp-tech-desk/how-much-does-bandwidth-actually-cost</ref><ref>https://businessonlybroadband.wordpress.com/2014/09/11/nielsens-law-of-internet-bandwidth-and-what-it-means-for-utilization/</ref>.<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 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>Lapp0https://en.bitcoin.it/w/index.php?title=Best_Practices&diff=57366Best Practices2015-07-09T01:35:58Z<p>Lapp0: /* Anonymity */</p>
<hr />
<div>Bitcoin is a trustless consensus system with no central authority. When you make a payment and it is confirmed into the blockchain, it is not feasible to have a "chargeback" unless the person you paid pays you back themselves. Over the years there have been many losses of money through hacks, scams, software failures and other incidents.<ref>[https://bitcointalk.org/index.php?topic=83794.0#post_toc_11 List of events by BTC value lost]</ref> It is important that Bitcoin investors, users and developers understand these risks so they can be mitigated.<br />
<br />
=Investing Risks=<br />
<br />
==Bitcoin==<br />
<br />
Bitcoin is a volatile asset. There is no promise that you won't lose all of your money when you buy bitcoin. In general, it is a good idea to understand something before you invest in it. In short, Bitcoin is a deflationary internet currency that requires a consensus system to work. This consensus system only works if a sufficient number of miners have the proper incentives to be honest. This means before buying bitcoins you should answer the following questions for yourself:<br />
* Is deflation [http://krugman.blogs.nytimes.com/2010/08/02/why-is-deflation-bad/ problematic] or [https://mises.org/library/deflating-deflation-myth not]? Is it problematic to the point that it will cause Bitcoin to fail?<br />
* How does the Bitcoin consensus system [https://bitcoin.org/bitcoin.pdf work]?<br />
* Are the [https://github.com/kanzure/bitcoin-incentives/blob/master/bitcoin-incentives.tex incentives] of Bitcoin miners and other users in the system sufficient for consensus?<br />
* Can Bitcoin gain sufficient merchants and users to sustain itself?<br />
* Is there some other reason Bitcoin might fail?<br />
<br />
When buying bitcoin, one should be aware of the risks that come with someone else holding their money. To reduce risk, your bitcoins or dollars should be traded on an exchange that you have researched and trust. Ideally, fiat and bitcoin should be on the exchange for as little time as possible.<br />
<br />
==Bitcoin Related Investments==<br />
<br />
Being a pseudonymous currency where users have little recourse if their money is stolen, Bitcoin attracts scammers. There have been many scams and thefts involving Bitcoin. Before giving someone else your money consider whether the offer is too good to be true, whether you can trust the potential bitcoin recipient and what your counterparty risk is.<br />
<br />
Some common scams or ripoffs are cloud mining, which usually only returns a fraction of what you pay them, and altcoins which often advertise themselves as being the "next big thing" and claim to solve some problem in Bitcoin, by breaking the security model.<ref>[https://download.wpsoftware.net/bitcoin/alts.pdf A Treatise On Altcoins]</ref><br />
<br />
=Use Risks=<br />
<br />
Once you have bought or earned Bitcoins, keeping them requires that no malicious party can spend the bitcoins in your wallet. If your computer is infected with malware then any time you decrypt your wallet the malware could potentially steal from you. <br />
<br />
==Wallet Types==<br />
<br />
Once you have chosen a wallet to use, you must [[Securing_your_wallet|create and use it securely]]. [https://bitcoin.org/en/choose-your-wallet Bitcoin.org] has a tool to view the security problems and benefits of many wallets.<br />
<br />
===Paper Wallets===<br />
<br />
A properly created [[Paper wallet]] removes the risk of theft-by-malware.<br />
<br />
===Centralized services===<br />
<br />
One of the main advantages of Bitcoin over traditional currencies is the lack of a requirement to trust someone else to own currency (trustlessness). When you give your money to a web wallet such as Coinbase, you are at risk of theft or some other form of loss.<ref>[https://bitcointalk.org/index.php?topic=83794.0#post_toc_11 List of events by BTC value lost]</ref> Services like Coinbase own your bitcoins and display a balance for you, but you aren't guaranteed to be able to spend that balance, you are trusting them.<br />
<br />
There are web wallets that don't store your private keys such as [[blockchain.info]]. However there are still many risks involved, the service could<br />
* withhold your private keys and extort you<br />
* send you malicious code that steals your money<br />
* lie about a payment to you costlessly<br />
* correlate your IP address with your transaction<br />
* have broken Javascript cryptography unintentionally<br />
<br />
Blockchain.info is particularly bad in terms of security and ethics. It is strongly recommended that individuals and businesses don't use them. They have had large thefts<ref>[https://www.cryptocoinsnews.com/gentleman-hacker-returns-stolen-bitcoins-blockchain-info/ GENTLEMAN HACKER RETURNS STOLEN BITCOINS TO BLOCKCHAIN.INFO]</ref> and vulnerabilities that allow attackers to lie about payments.<ref>[https://www.cryptocoinsnews.com/blockchain-info-bug-one-month-fix/ Blockchain.info Bug Took One Month to Fix]</ref><br />
<br />
===Local Wallets===<br />
<br />
[[Thin_Client_Security#Simplified_Payment_Verification_.28SPV.29|SPV thin clients]] allow you to have a secure wallet with the assumption that the majority of the mining power isn't malicious. These clients verify that a block exists and there was sufficient work done on it, but not that it was valid. Not verifying a block takes orders of magnitude less disk space, bandwidth and processing power, however if a miner has a significant portion of the network hashrate, they can send you an invalid blockchain that has had more work done on it than the valid mainchain. This invalid blockchain might contain an invalid transaction that pays you money that doesn't exist. It is expensive to use a large portion of the network hashrate to attack, so SPV clients may be considered to have a "good enough" level of security for small payments.<br />
<br />
If you are handling a large amount of money, you should use a full-node client that verifies every block, such as Bitcoin Core. When a payment is made to you, it can be reversed with some probability by an attacking miner. As you receive more [[Confirmation|Confirmations]] it becomes exponentially more expensive for an attacker to reverse a payment to you. Unconfirmed transactions have no guarantee and can be doublespent for free.<br />
<br />
If you use a full node with a consensus reimplementation such as btcd, there is a risk you will lose consensus with the rest of the network and be vulnerable to attacks cheaper than attacks on SPV clients.<br />
<br />
==Improper Handling Of Money==<br />
<br />
[[Address reuse]] should be avoided, addresses should be used as invoices. The use of "[[From address|From addresses]]" (which don't actually exist<ref>[https://iwilcox.me.uk/2014/no-from-address There Is No 'From' Address]</ref>) cause confusion, there is no guarantee that a payer controls this address and paying back to it may cause loss of funds.<br />
<br />
==Anonymity==<br />
<br />
Bitcoin is not anonymous, it is pseudonymous. If you reuse addresses you will link your private payments together. If your software redeems multiple transactions paid to you to form a single transaction, as is it typically does, the redeemed transactions may be correlated.<br />
<br />
=Development Risks=<br />
<br />
Using the [[Testnet]] is recommended. The Bitcoins on this network are designed to be valueless and there is no risk of monetary loss if your software has unexpected behavior while testing. If none of the faucets are working you can ask for testnetcoins on Freenodes #bitcoin-dev.<br />
<br />
Your software should NOT use the gettransaction [[Original_Bitcoin_client/API_Calls_list|API call]] to verify that payments are in the blockchain due to [[Transaction Malleability|transaction malleability]]. Instead you can use listsinceblock. <br />
<br />
Your businesses software should not handle others money in most cases. If you are planning on handling others bitcoins, the system should be developed by a professional developer with a strong understanding of cryptography and bitcoin.<br />
<br />
==References==<br />
<br />
<references/></div>Lapp0https://en.bitcoin.it/w/index.php?title=Best_Practices&diff=57365Best Practices2015-07-09T01:32:37Z<p>Lapp0: /* Local Wallets */</p>
<hr />
<div>Bitcoin is a trustless consensus system with no central authority. When you make a payment and it is confirmed into the blockchain, it is not feasible to have a "chargeback" unless the person you paid pays you back themselves. Over the years there have been many losses of money through hacks, scams, software failures and other incidents.<ref>[https://bitcointalk.org/index.php?topic=83794.0#post_toc_11 List of events by BTC value lost]</ref> It is important that Bitcoin investors, users and developers understand these risks so they can be mitigated.<br />
<br />
=Investing Risks=<br />
<br />
==Bitcoin==<br />
<br />
Bitcoin is a volatile asset. There is no promise that you won't lose all of your money when you buy bitcoin. In general, it is a good idea to understand something before you invest in it. In short, Bitcoin is a deflationary internet currency that requires a consensus system to work. This consensus system only works if a sufficient number of miners have the proper incentives to be honest. This means before buying bitcoins you should answer the following questions for yourself:<br />
* Is deflation [http://krugman.blogs.nytimes.com/2010/08/02/why-is-deflation-bad/ problematic] or [https://mises.org/library/deflating-deflation-myth not]? Is it problematic to the point that it will cause Bitcoin to fail?<br />
* How does the Bitcoin consensus system [https://bitcoin.org/bitcoin.pdf work]?<br />
* Are the [https://github.com/kanzure/bitcoin-incentives/blob/master/bitcoin-incentives.tex incentives] of Bitcoin miners and other users in the system sufficient for consensus?<br />
* Can Bitcoin gain sufficient merchants and users to sustain itself?<br />
* Is there some other reason Bitcoin might fail?<br />
<br />
When buying bitcoin, one should be aware of the risks that come with someone else holding their money. To reduce risk, your bitcoins or dollars should be traded on an exchange that you have researched and trust. Ideally, fiat and bitcoin should be on the exchange for as little time as possible.<br />
<br />
==Bitcoin Related Investments==<br />
<br />
Being a pseudonymous currency where users have little recourse if their money is stolen, Bitcoin attracts scammers. There have been many scams and thefts involving Bitcoin. Before giving someone else your money consider whether the offer is too good to be true, whether you can trust the potential bitcoin recipient and what your counterparty risk is.<br />
<br />
Some common scams or ripoffs are cloud mining, which usually only returns a fraction of what you pay them, and altcoins which often advertise themselves as being the "next big thing" and claim to solve some problem in Bitcoin, by breaking the security model.<ref>[https://download.wpsoftware.net/bitcoin/alts.pdf A Treatise On Altcoins]</ref><br />
<br />
=Use Risks=<br />
<br />
Once you have bought or earned Bitcoins, keeping them requires that no malicious party can spend the bitcoins in your wallet. If your computer is infected with malware then any time you decrypt your wallet the malware could potentially steal from you. <br />
<br />
==Wallet Types==<br />
<br />
Once you have chosen a wallet to use, you must [[Securing_your_wallet|create and use it securely]]. [https://bitcoin.org/en/choose-your-wallet Bitcoin.org] has a tool to view the security problems and benefits of many wallets.<br />
<br />
===Paper Wallets===<br />
<br />
A properly created [[Paper wallet]] removes the risk of theft-by-malware.<br />
<br />
===Centralized services===<br />
<br />
One of the main advantages of Bitcoin over traditional currencies is the lack of a requirement to trust someone else to own currency (trustlessness). When you give your money to a web wallet such as Coinbase, you are at risk of theft or some other form of loss.<ref>[https://bitcointalk.org/index.php?topic=83794.0#post_toc_11 List of events by BTC value lost]</ref> Services like Coinbase own your bitcoins and display a balance for you, but you aren't guaranteed to be able to spend that balance, you are trusting them.<br />
<br />
There are web wallets that don't store your private keys such as [[blockchain.info]]. However there are still many risks involved, the service could<br />
* withhold your private keys and extort you<br />
* send you malicious code that steals your money<br />
* lie about a payment to you costlessly<br />
* correlate your IP address with your transaction<br />
* have broken Javascript cryptography unintentionally<br />
<br />
Blockchain.info is particularly bad in terms of security and ethics. It is strongly recommended that individuals and businesses don't use them. They have had large thefts<ref>[https://www.cryptocoinsnews.com/gentleman-hacker-returns-stolen-bitcoins-blockchain-info/ GENTLEMAN HACKER RETURNS STOLEN BITCOINS TO BLOCKCHAIN.INFO]</ref> and vulnerabilities that allow attackers to lie about payments.<ref>[https://www.cryptocoinsnews.com/blockchain-info-bug-one-month-fix/ Blockchain.info Bug Took One Month to Fix]</ref><br />
<br />
===Local Wallets===<br />
<br />
[[Thin_Client_Security#Simplified_Payment_Verification_.28SPV.29|SPV thin clients]] allow you to have a secure wallet with the assumption that the majority of the mining power isn't malicious. These clients verify that a block exists and there was sufficient work done on it, but not that it was valid. Not verifying a block takes orders of magnitude less disk space, bandwidth and processing power, however if a miner has a significant portion of the network hashrate, they can send you an invalid blockchain that has had more work done on it than the valid mainchain. This invalid blockchain might contain an invalid transaction that pays you money that doesn't exist. It is expensive to use a large portion of the network hashrate to attack, so SPV clients may be considered to have a "good enough" level of security for small payments.<br />
<br />
If you are handling a large amount of money, you should use a full-node client that verifies every block, such as Bitcoin Core. When a payment is made to you, it can be reversed with some probability by an attacking miner. As you receive more [[Confirmation|Confirmations]] it becomes exponentially more expensive for an attacker to reverse a payment to you. Unconfirmed transactions have no guarantee and can be doublespent for free.<br />
<br />
If you use a full node with a consensus reimplementation such as btcd, there is a risk you will lose consensus with the rest of the network and be vulnerable to attacks cheaper than attacks on SPV clients.<br />
<br />
==Improper Handling Of Money==<br />
<br />
[[Address reuse]] should be avoided, addresses should be used as invoices. The use of "[[From address|From addresses]]" (which don't actually exist<ref>[https://iwilcox.me.uk/2014/no-from-address There Is No 'From' Address]</ref>) cause confusion, there is no guarantee that a payer controls this address and paying back to it may cause loss of funds.<br />
<br />
==Anonymity==<br />
<br />
Bitcoin is not anonymous, it is pseudonymous. If you reuse addresses you will link your private payments together.<br />
<br />
=Development Risks=<br />
<br />
Using the [[Testnet]] is recommended. The Bitcoins on this network are designed to be valueless and there is no risk of monetary loss if your software has unexpected behavior while testing. If none of the faucets are working you can ask for testnetcoins on Freenodes #bitcoin-dev.<br />
<br />
Your software should NOT use the gettransaction [[Original_Bitcoin_client/API_Calls_list|API call]] to verify that payments are in the blockchain due to [[Transaction Malleability|transaction malleability]]. Instead you can use listsinceblock. <br />
<br />
Your businesses software should not handle others money in most cases. If you are planning on handling others bitcoins, the system should be developed by a professional developer with a strong understanding of cryptography and bitcoin.<br />
<br />
==References==<br />
<br />
<references/></div>Lapp0https://en.bitcoin.it/w/index.php?title=Best_Practices&diff=57364Best Practices2015-07-09T01:29:22Z<p>Lapp0: /* Local Wallets */</p>
<hr />
<div>Bitcoin is a trustless consensus system with no central authority. When you make a payment and it is confirmed into the blockchain, it is not feasible to have a "chargeback" unless the person you paid pays you back themselves. Over the years there have been many losses of money through hacks, scams, software failures and other incidents.<ref>[https://bitcointalk.org/index.php?topic=83794.0#post_toc_11 List of events by BTC value lost]</ref> It is important that Bitcoin investors, users and developers understand these risks so they can be mitigated.<br />
<br />
=Investing Risks=<br />
<br />
==Bitcoin==<br />
<br />
Bitcoin is a volatile asset. There is no promise that you won't lose all of your money when you buy bitcoin. In general, it is a good idea to understand something before you invest in it. In short, Bitcoin is a deflationary internet currency that requires a consensus system to work. This consensus system only works if a sufficient number of miners have the proper incentives to be honest. This means before buying bitcoins you should answer the following questions for yourself:<br />
* Is deflation [http://krugman.blogs.nytimes.com/2010/08/02/why-is-deflation-bad/ problematic] or [https://mises.org/library/deflating-deflation-myth not]? Is it problematic to the point that it will cause Bitcoin to fail?<br />
* How does the Bitcoin consensus system [https://bitcoin.org/bitcoin.pdf work]?<br />
* Are the [https://github.com/kanzure/bitcoin-incentives/blob/master/bitcoin-incentives.tex incentives] of Bitcoin miners and other users in the system sufficient for consensus?<br />
* Can Bitcoin gain sufficient merchants and users to sustain itself?<br />
* Is there some other reason Bitcoin might fail?<br />
<br />
When buying bitcoin, one should be aware of the risks that come with someone else holding their money. To reduce risk, your bitcoins or dollars should be traded on an exchange that you have researched and trust. Ideally, fiat and bitcoin should be on the exchange for as little time as possible.<br />
<br />
==Bitcoin Related Investments==<br />
<br />
Being a pseudonymous currency where users have little recourse if their money is stolen, Bitcoin attracts scammers. There have been many scams and thefts involving Bitcoin. Before giving someone else your money consider whether the offer is too good to be true, whether you can trust the potential bitcoin recipient and what your counterparty risk is.<br />
<br />
Some common scams or ripoffs are cloud mining, which usually only returns a fraction of what you pay them, and altcoins which often advertise themselves as being the "next big thing" and claim to solve some problem in Bitcoin, by breaking the security model.<ref>[https://download.wpsoftware.net/bitcoin/alts.pdf A Treatise On Altcoins]</ref><br />
<br />
=Use Risks=<br />
<br />
Once you have bought or earned Bitcoins, keeping them requires that no malicious party can spend the bitcoins in your wallet. If your computer is infected with malware then any time you decrypt your wallet the malware could potentially steal from you. <br />
<br />
==Wallet Types==<br />
<br />
Once you have chosen a wallet to use, you must [[Securing_your_wallet|create and use it securely]]. [https://bitcoin.org/en/choose-your-wallet Bitcoin.org] has a tool to view the security problems and benefits of many wallets.<br />
<br />
===Paper Wallets===<br />
<br />
A properly created [[Paper wallet]] removes the risk of theft-by-malware.<br />
<br />
===Centralized services===<br />
<br />
One of the main advantages of Bitcoin over traditional currencies is the lack of a requirement to trust someone else to own currency (trustlessness). When you give your money to a web wallet such as Coinbase, you are at risk of theft or some other form of loss.<ref>[https://bitcointalk.org/index.php?topic=83794.0#post_toc_11 List of events by BTC value lost]</ref> Services like Coinbase own your bitcoins and display a balance for you, but you aren't guaranteed to be able to spend that balance, you are trusting them.<br />
<br />
There are web wallets that don't store your private keys such as [[blockchain.info]]. However there are still many risks involved, the service could<br />
* withhold your private keys and extort you<br />
* send you malicious code that steals your money<br />
* lie about a payment to you costlessly<br />
* correlate your IP address with your transaction<br />
* have broken Javascript cryptography unintentionally<br />
<br />
Blockchain.info is particularly bad in terms of security and ethics. It is strongly recommended that individuals and businesses don't use them. They have had large thefts<ref>[https://www.cryptocoinsnews.com/gentleman-hacker-returns-stolen-bitcoins-blockchain-info/ GENTLEMAN HACKER RETURNS STOLEN BITCOINS TO BLOCKCHAIN.INFO]</ref> and vulnerabilities that allow attackers to lie about payments.<ref>[https://www.cryptocoinsnews.com/blockchain-info-bug-one-month-fix/ Blockchain.info Bug Took One Month to Fix]</ref><br />
<br />
===Local Wallets===<br />
<br />
[[Thin_Client_Security#Simplified_Payment_Verification_.28SPV.29|SPV thin clients]] allow you to have a secure wallet with the assumption that the majority of the mining power isn't malicious. These clients verify that a block exists and there was sufficient work done on it, but not that it was valid. Not verifying a block takes orders of magnitude less disk space, bandwidth and processing power, however if a miner has a significant portion of the network hashrate, they can send you an invalid blockchain that has had more work done on it than the valid mainchain. This invalid blockchain might contain an invalid transaction that pays you money that doesn't exist. It is expensive to obtain 51% of the network hashrate, so SPV clients have a "good enough" level of security for small payments.<br />
<br />
If you are storing and handling a large amount of money, you should use a full-node client that verifies every block such as Bitcoin Core. When a payment is made to you, it can be reversed with some probability by an attacking miner. As you receive more [[Confirmation|Confirmations]] it becomes exponentially more expensive for an attacker to doublespend a payment to you. Unconfirmed transactions have no guarantee and can be doublespent.<br />
<br />
If you use a full node with a consensus reimplementation such as btcd, there is a risk you will lose consensus with the rest of the network.<br />
<br />
==Improper Handling Of Money==<br />
<br />
[[Address reuse]] should be avoided, addresses should be used as invoices. The use of "[[From address|From addresses]]" (which don't actually exist<ref>[https://iwilcox.me.uk/2014/no-from-address There Is No 'From' Address]</ref>) cause confusion, there is no guarantee that a payer controls this address and paying back to it may cause loss of funds.<br />
<br />
==Anonymity==<br />
<br />
Bitcoin is not anonymous, it is pseudonymous. If you reuse addresses you will link your private payments together.<br />
<br />
=Development Risks=<br />
<br />
Using the [[Testnet]] is recommended. The Bitcoins on this network are designed to be valueless and there is no risk of monetary loss if your software has unexpected behavior while testing. If none of the faucets are working you can ask for testnetcoins on Freenodes #bitcoin-dev.<br />
<br />
Your software should NOT use the gettransaction [[Original_Bitcoin_client/API_Calls_list|API call]] to verify that payments are in the blockchain due to [[Transaction Malleability|transaction malleability]]. Instead you can use listsinceblock. <br />
<br />
Your businesses software should not handle others money in most cases. If you are planning on handling others bitcoins, the system should be developed by a professional developer with a strong understanding of cryptography and bitcoin.<br />
<br />
==References==<br />
<br />
<references/></div>Lapp0https://en.bitcoin.it/w/index.php?title=Best_Practices&diff=57363Best Practices2015-07-09T01:28:40Z<p>Lapp0: /* Local Wallets */</p>
<hr />
<div>Bitcoin is a trustless consensus system with no central authority. When you make a payment and it is confirmed into the blockchain, it is not feasible to have a "chargeback" unless the person you paid pays you back themselves. Over the years there have been many losses of money through hacks, scams, software failures and other incidents.<ref>[https://bitcointalk.org/index.php?topic=83794.0#post_toc_11 List of events by BTC value lost]</ref> It is important that Bitcoin investors, users and developers understand these risks so they can be mitigated.<br />
<br />
=Investing Risks=<br />
<br />
==Bitcoin==<br />
<br />
Bitcoin is a volatile asset. There is no promise that you won't lose all of your money when you buy bitcoin. In general, it is a good idea to understand something before you invest in it. In short, Bitcoin is a deflationary internet currency that requires a consensus system to work. This consensus system only works if a sufficient number of miners have the proper incentives to be honest. This means before buying bitcoins you should answer the following questions for yourself:<br />
* Is deflation [http://krugman.blogs.nytimes.com/2010/08/02/why-is-deflation-bad/ problematic] or [https://mises.org/library/deflating-deflation-myth not]? Is it problematic to the point that it will cause Bitcoin to fail?<br />
* How does the Bitcoin consensus system [https://bitcoin.org/bitcoin.pdf work]?<br />
* Are the [https://github.com/kanzure/bitcoin-incentives/blob/master/bitcoin-incentives.tex incentives] of Bitcoin miners and other users in the system sufficient for consensus?<br />
* Can Bitcoin gain sufficient merchants and users to sustain itself?<br />
* Is there some other reason Bitcoin might fail?<br />
<br />
When buying bitcoin, one should be aware of the risks that come with someone else holding their money. To reduce risk, your bitcoins or dollars should be traded on an exchange that you have researched and trust. Ideally, fiat and bitcoin should be on the exchange for as little time as possible.<br />
<br />
==Bitcoin Related Investments==<br />
<br />
Being a pseudonymous currency where users have little recourse if their money is stolen, Bitcoin attracts scammers. There have been many scams and thefts involving Bitcoin. Before giving someone else your money consider whether the offer is too good to be true, whether you can trust the potential bitcoin recipient and what your counterparty risk is.<br />
<br />
Some common scams or ripoffs are cloud mining, which usually only returns a fraction of what you pay them, and altcoins which often advertise themselves as being the "next big thing" and claim to solve some problem in Bitcoin, by breaking the security model.<ref>[https://download.wpsoftware.net/bitcoin/alts.pdf A Treatise On Altcoins]</ref><br />
<br />
=Use Risks=<br />
<br />
Once you have bought or earned Bitcoins, keeping them requires that no malicious party can spend the bitcoins in your wallet. If your computer is infected with malware then any time you decrypt your wallet the malware could potentially steal from you. <br />
<br />
==Wallet Types==<br />
<br />
Once you have chosen a wallet to use, you must [[Securing_your_wallet|create and use it securely]]. [https://bitcoin.org/en/choose-your-wallet Bitcoin.org] has a tool to view the security problems and benefits of many wallets.<br />
<br />
===Paper Wallets===<br />
<br />
A properly created [[Paper wallet]] removes the risk of theft-by-malware.<br />
<br />
===Centralized services===<br />
<br />
One of the main advantages of Bitcoin over traditional currencies is the lack of a requirement to trust someone else to own currency (trustlessness). When you give your money to a web wallet such as Coinbase, you are at risk of theft or some other form of loss.<ref>[https://bitcointalk.org/index.php?topic=83794.0#post_toc_11 List of events by BTC value lost]</ref> Services like Coinbase own your bitcoins and display a balance for you, but you aren't guaranteed to be able to spend that balance, you are trusting them.<br />
<br />
There are web wallets that don't store your private keys such as [[blockchain.info]]. However there are still many risks involved, the service could<br />
* withhold your private keys and extort you<br />
* send you malicious code that steals your money<br />
* lie about a payment to you costlessly<br />
* correlate your IP address with your transaction<br />
* have broken Javascript cryptography unintentionally<br />
<br />
Blockchain.info is particularly bad in terms of security and ethics. It is strongly recommended that individuals and businesses don't use them. They have had large thefts<ref>[https://www.cryptocoinsnews.com/gentleman-hacker-returns-stolen-bitcoins-blockchain-info/ GENTLEMAN HACKER RETURNS STOLEN BITCOINS TO BLOCKCHAIN.INFO]</ref> and vulnerabilities that allow attackers to lie about payments.<ref>[https://www.cryptocoinsnews.com/blockchain-info-bug-one-month-fix/ Blockchain.info Bug Took One Month to Fix]</ref><br />
<br />
===Local Wallets===<br />
<br />
[[Thin_Client_Security#Simplified_Payment_Verification_.28SPV.29|SPV thin clients]] allow you to have a secure wallet with the assumption that the majority of the mining power isn't malicious. These clients verify that a block exists and there was sufficient work done on it, but not that it was valid. Not verifying a block takes orders of magnitude less disk space, bandwidth and processing power, however if a miner has 51% of the network hashrate, they can send you an invalid blockchain that has had more work done on it than the valid mainchain. This invalid blockchain might contain an invalid transaction that pays you money that doesn't exist. It is expensive to obtain 51% of the network hashrate, so SPV clients have a "good enough" level of security for small payments.<br />
<br />
If you are storing and handling a large amount of money, you should use a full-node client that verifies every block such as Bitcoin Core. When a payment is made to you, it can be reversed with some probability by an attacking miner. As you receive more [[Confirmation|Confirmations]] it becomes exponentially more expensive for an attacker to doublespend a payment to you. Unconfirmed transactions have no guarantee and can be doublespent.<br />
<br />
If you use a full node with a consensus reimplementation such as btcd, there is a risk you will lose consensus with the rest of the network.<br />
<br />
==Improper Handling Of Money==<br />
<br />
[[Address reuse]] should be avoided, addresses should be used as invoices. The use of "[[From address|From addresses]]" (which don't actually exist<ref>[https://iwilcox.me.uk/2014/no-from-address There Is No 'From' Address]</ref>) cause confusion, there is no guarantee that a payer controls this address and paying back to it may cause loss of funds.<br />
<br />
==Anonymity==<br />
<br />
Bitcoin is not anonymous, it is pseudonymous. If you reuse addresses you will link your private payments together.<br />
<br />
=Development Risks=<br />
<br />
Using the [[Testnet]] is recommended. The Bitcoins on this network are designed to be valueless and there is no risk of monetary loss if your software has unexpected behavior while testing. If none of the faucets are working you can ask for testnetcoins on Freenodes #bitcoin-dev.<br />
<br />
Your software should NOT use the gettransaction [[Original_Bitcoin_client/API_Calls_list|API call]] to verify that payments are in the blockchain due to [[Transaction Malleability|transaction malleability]]. Instead you can use listsinceblock. <br />
<br />
Your businesses software should not handle others money in most cases. If you are planning on handling others bitcoins, the system should be developed by a professional developer with a strong understanding of cryptography and bitcoin.<br />
<br />
==References==<br />
<br />
<references/></div>Lapp0https://en.bitcoin.it/w/index.php?title=Softfork&diff=57174Softfork2015-07-06T08:00:32Z<p>Lapp0: /* 2015 BIP66 Blockchain Fork */</p>
<hr />
<div>A softfork is a change to the bitcoin protocol wherein only previously valid blocks/transactions are made invalid.<br />
Since old nodes will recognise the new blocks as valid, a softfork is backward-compatible.<br />
This kind of fork requires only a majority of the miners upgrading to enforce the new rules.<br />
<br />
New transaction types can often be added as softforks, requiring only that the participants (sender and receiver) and miners understand the new transaction type.<br />
This is done by having the new transaction appear to older clients as a "pay-to-anybody" transaction (of a special form), and getting the miners to agree to reject blocks including these transaction unless the transaction validates under the new rules.<br />
This is how [[P2SH]] was added to Bitcoin.<br />
<br />
==Mechanism==<br />
<br />
Given a set of valid blocks, you can take any subset of those blocks and that subset will also, of course, all be valid. A softfork changes the rules such that only a subset of blocks that were previously valid remain so. Often softforks make certain transactions invalid, for example a softfork could make any transaction that is more than 1KB invalid (not that that would necessarily be desirable).<br />
<br />
Generally softforks accomplish something more useful, for example Pay-to-Script-Hash ([[P2SH]]) was a softfork. Originally the script "OP_HASH160 [20-byte-hash-value] OP_EQUAL" could be redeemed by simply pushing the preimage of the hashed value onto the stack. Now the value you push must be a script that evaluates to true. All new transactions with the script "OP_HASH160 [20-byte-hash-value] OP_EQUAL" weren't valid if they merely had a preimage of the hash pushed onto the stack, the preimage had to be a valid script. The requirement for the preimage being a valid script shrunk the set of valid transactions and added a feature at the same time.<br />
<br />
In the P2SH example, two opcodes were redefined so they had a new function. You can also add new opcodes that originally didn't do anything. Because the new rules must cause the set of valid blocks to be a proper subset of the valid blocks with the old rules, you must ensure that adding this new opcode doesn't cause transactions that were once invalid to be valid. In [[BIP12]] OP_EVAL is proposed. To softfork this new opcode in, the proposal stated an opcode that previously didn't have any effect would be replaced. The script would be evaluated twice, once with the opcode having the new OP_EVAL behavior and once with it's old behavior of doing nothing. The script being run with the old behavior of doing nothing would ensure that the transaction was valid to old clients.<br />
<br />
==Security==<br />
<br />
In order for a softfork to work, a majority of the mining power needs to be running a client recognizing the fork. The more miners you have, the more secure secure the network is postfork. If you have 3/4 of miners recognizing the fork, 1/4 blocks created aren't guaranteed to follow the new rules. These 1/4 blocks will be valid to old nodes that aren't aware of the new rules, but they will be ignored by new nodes. This allows a "fake confirmation" vulnerability, an attacker could create a transaction paying to their victim, but have it end up in a block not following new rules, they might bribe a miner to make the block incompatible with new rules or make the transaction itself incompatible. Because 3/4 the hashrate won't mine on top of the block, the block and the transaction paying to you will eventually not be in the "mainchain" allowing the attacker to attempt to doublespend.<br />
<br />
These attacks can be avoided by upgrading your client, however if the vast majority of miners (>95%) accept the new rules, the odds of an attacker being able to create many fake confirmations is low. Because miners want to make money, and without upgrading their blocks may be reorged out, there is an incentive for miners to upgrade and 100% acceptance of a fork should be achieved by miners quickly.<br />
<br />
===2015 BIP66 Blockchain Fork===<br />
<br />
After the deployment of the BIP66 softfork in 2015 95% of hash power stated that they accepted BIP66 by setting their block version to 3. In theory setting your block version to 3 is an agreement with the network to consider version 2 blocks invalid and only mine on valid forks. Being part of the 5% that hadn't updated and weren't creating version 3 blocks, BTCNuggets created a version 2 block which was invalid to all new clients (>=0.9.5) but valid to old clients. Antminer and F2Pool, comprising ~40% of the network at the time, were creating version 3 blocks, however neither miner validated previous blocks. This caused both Antminer and F2Pool to mine on top of BTCNuggets version 2 block and create an invalid fork. Over 40% of the hashpower was mining on this version 2 fork despite 95% having "agreed" to not do so. This led to a 6 block fork that was resolved after contacting the F2Pool and Antminer pool owners.<br />
<br />
Any SPV clients or out of date clients were vulnerable to these fake confirmations and in theory there could have been a reversed 6 confirmation transaction. Fortunately there were zero doublespent confirmed transactions and the only money lost was mining revenue that these pools lost. F2Pool has continued mining without validating beforehand and SPV client as well as outdated full node clients are at an even higher risk as long as they do so.<br />
<br />
==Implications==<br />
<br />
Softforks don't require any nodes to upgrade to maintain consensus since all blocks with the new softforked in rules also follow the old rules, therefore old clients accept them. Softforks cannot be reversed without a hardfork since a softfork by definition only allows the set of valid blocks to be a proper subset of what was valid pre-fork.<br />
<br />
If users upgrade to a post-softfork client and for some reason a majority of miners switch back to the pre-softfork client, the post-softfork client users would break consensus as soon as a block came along that didn't follow their clients new rules.<br />
<br />
See also: [[Hardfork]]</div>Lapp0https://en.bitcoin.it/w/index.php?title=Softfork&diff=57173Softfork2015-07-06T07:59:45Z<p>Lapp0: /* 2015 BIP66 Blockchain Fork */</p>
<hr />
<div>A softfork is a change to the bitcoin protocol wherein only previously valid blocks/transactions are made invalid.<br />
Since old nodes will recognise the new blocks as valid, a softfork is backward-compatible.<br />
This kind of fork requires only a majority of the miners upgrading to enforce the new rules.<br />
<br />
New transaction types can often be added as softforks, requiring only that the participants (sender and receiver) and miners understand the new transaction type.<br />
This is done by having the new transaction appear to older clients as a "pay-to-anybody" transaction (of a special form), and getting the miners to agree to reject blocks including these transaction unless the transaction validates under the new rules.<br />
This is how [[P2SH]] was added to Bitcoin.<br />
<br />
==Mechanism==<br />
<br />
Given a set of valid blocks, you can take any subset of those blocks and that subset will also, of course, all be valid. A softfork changes the rules such that only a subset of blocks that were previously valid remain so. Often softforks make certain transactions invalid, for example a softfork could make any transaction that is more than 1KB invalid (not that that would necessarily be desirable).<br />
<br />
Generally softforks accomplish something more useful, for example Pay-to-Script-Hash ([[P2SH]]) was a softfork. Originally the script "OP_HASH160 [20-byte-hash-value] OP_EQUAL" could be redeemed by simply pushing the preimage of the hashed value onto the stack. Now the value you push must be a script that evaluates to true. All new transactions with the script "OP_HASH160 [20-byte-hash-value] OP_EQUAL" weren't valid if they merely had a preimage of the hash pushed onto the stack, the preimage had to be a valid script. The requirement for the preimage being a valid script shrunk the set of valid transactions and added a feature at the same time.<br />
<br />
In the P2SH example, two opcodes were redefined so they had a new function. You can also add new opcodes that originally didn't do anything. Because the new rules must cause the set of valid blocks to be a proper subset of the valid blocks with the old rules, you must ensure that adding this new opcode doesn't cause transactions that were once invalid to be valid. In [[BIP12]] OP_EVAL is proposed. To softfork this new opcode in, the proposal stated an opcode that previously didn't have any effect would be replaced. The script would be evaluated twice, once with the opcode having the new OP_EVAL behavior and once with it's old behavior of doing nothing. The script being run with the old behavior of doing nothing would ensure that the transaction was valid to old clients.<br />
<br />
==Security==<br />
<br />
In order for a softfork to work, a majority of the mining power needs to be running a client recognizing the fork. The more miners you have, the more secure secure the network is postfork. If you have 3/4 of miners recognizing the fork, 1/4 blocks created aren't guaranteed to follow the new rules. These 1/4 blocks will be valid to old nodes that aren't aware of the new rules, but they will be ignored by new nodes. This allows a "fake confirmation" vulnerability, an attacker could create a transaction paying to their victim, but have it end up in a block not following new rules, they might bribe a miner to make the block incompatible with new rules or make the transaction itself incompatible. Because 3/4 the hashrate won't mine on top of the block, the block and the transaction paying to you will eventually not be in the "mainchain" allowing the attacker to attempt to doublespend.<br />
<br />
These attacks can be avoided by upgrading your client, however if the vast majority of miners (>95%) accept the new rules, the odds of an attacker being able to create many fake confirmations is low. Because miners want to make money, and without upgrading their blocks may be reorged out, there is an incentive for miners to upgrade and 100% acceptance of a fork should be achieved by miners quickly.<br />
<br />
===2015 BIP66 Blockchain Fork===<br />
<br />
After the deployment of the BIP66 softfork in 2015 95% of hash power stated that they accepted BIP66 by setting their block version to 3. In theory setting your block version to 3 is an agreement with the network to consider version 2 blocks invalid and only mine on valid forks. Being part of the 5% that hadn't updated and weren't creating version 3 blocks, BTCNuggets created a version 2 block which was invalid to all new clients (>=0.9.5) but valid to old clients. Antminer and F2Pool, comprising ~40% of the network at the time, were creating version 3 blocks, however neither miner validated previous blocks. This caused both Antminer and F2Pool to mine on top of BTCNuggets version 2 block and create an invalid fork. Over 40% of the hashpower was mining on this version 2 fork despite 95% having "agreed" to not do so. This led to a 6 block fork that was resolved after contacting the F2Pool and Antminer pool owners.<br />
<br />
Any SPV clients or out of date clients were vulnerable to these fake confirmations and in theory there could have been a reversed 6 confirmation transaction. Fortunately there were zero doublespent confirmed transactions and the only money lost was mining revenue that these pools lost. F2Pool has continued mining without validating beforehand and SPV client as well as outdated full node clients are at risk as long as they do so.<br />
<br />
==Implications==<br />
<br />
Softforks don't require any nodes to upgrade to maintain consensus since all blocks with the new softforked in rules also follow the old rules, therefore old clients accept them. Softforks cannot be reversed without a hardfork since a softfork by definition only allows the set of valid blocks to be a proper subset of what was valid pre-fork.<br />
<br />
If users upgrade to a post-softfork client and for some reason a majority of miners switch back to the pre-softfork client, the post-softfork client users would break consensus as soon as a block came along that didn't follow their clients new rules.<br />
<br />
See also: [[Hardfork]]</div>Lapp0https://en.bitcoin.it/w/index.php?title=Softfork&diff=57172Softfork2015-07-06T07:56:39Z<p>Lapp0: /* Security */</p>
<hr />
<div>A softfork is a change to the bitcoin protocol wherein only previously valid blocks/transactions are made invalid.<br />
Since old nodes will recognise the new blocks as valid, a softfork is backward-compatible.<br />
This kind of fork requires only a majority of the miners upgrading to enforce the new rules.<br />
<br />
New transaction types can often be added as softforks, requiring only that the participants (sender and receiver) and miners understand the new transaction type.<br />
This is done by having the new transaction appear to older clients as a "pay-to-anybody" transaction (of a special form), and getting the miners to agree to reject blocks including these transaction unless the transaction validates under the new rules.<br />
This is how [[P2SH]] was added to Bitcoin.<br />
<br />
==Mechanism==<br />
<br />
Given a set of valid blocks, you can take any subset of those blocks and that subset will also, of course, all be valid. A softfork changes the rules such that only a subset of blocks that were previously valid remain so. Often softforks make certain transactions invalid, for example a softfork could make any transaction that is more than 1KB invalid (not that that would necessarily be desirable).<br />
<br />
Generally softforks accomplish something more useful, for example Pay-to-Script-Hash ([[P2SH]]) was a softfork. Originally the script "OP_HASH160 [20-byte-hash-value] OP_EQUAL" could be redeemed by simply pushing the preimage of the hashed value onto the stack. Now the value you push must be a script that evaluates to true. All new transactions with the script "OP_HASH160 [20-byte-hash-value] OP_EQUAL" weren't valid if they merely had a preimage of the hash pushed onto the stack, the preimage had to be a valid script. The requirement for the preimage being a valid script shrunk the set of valid transactions and added a feature at the same time.<br />
<br />
In the P2SH example, two opcodes were redefined so they had a new function. You can also add new opcodes that originally didn't do anything. Because the new rules must cause the set of valid blocks to be a proper subset of the valid blocks with the old rules, you must ensure that adding this new opcode doesn't cause transactions that were once invalid to be valid. In [[BIP12]] OP_EVAL is proposed. To softfork this new opcode in, the proposal stated an opcode that previously didn't have any effect would be replaced. The script would be evaluated twice, once with the opcode having the new OP_EVAL behavior and once with it's old behavior of doing nothing. The script being run with the old behavior of doing nothing would ensure that the transaction was valid to old clients.<br />
<br />
==Security==<br />
<br />
In order for a softfork to work, a majority of the mining power needs to be running a client recognizing the fork. The more miners you have, the more secure secure the network is postfork. If you have 3/4 of miners recognizing the fork, 1/4 blocks created aren't guaranteed to follow the new rules. These 1/4 blocks will be valid to old nodes that aren't aware of the new rules, but they will be ignored by new nodes. This allows a "fake confirmation" vulnerability, an attacker could create a transaction paying to their victim, but have it end up in a block not following new rules, they might bribe a miner to make the block incompatible with new rules or make the transaction itself incompatible. Because 3/4 the hashrate won't mine on top of the block, the block and the transaction paying to you will eventually not be in the "mainchain" allowing the attacker to attempt to doublespend.<br />
<br />
These attacks can be avoided by upgrading your client, however if the vast majority of miners (>95%) accept the new rules, the odds of an attacker being able to create many fake confirmations is low. Because miners want to make money, and without upgrading their blocks may be reorged out, there is an incentive for miners to upgrade and 100% acceptance of a fork should be achieved by miners quickly.<br />
<br />
===2015 BIP66 Blockchain Fork===<br />
<br />
After the deployment of the BIP66 softfork in 2015 95% of hash power stated that they accepted BIP66 by setting their block version to 3. In theory setting your block version to 3 is an agreement with the network to consider version 2 blocks invalid and only mine on valid forks. Being part of the 5% that hadn't updated and weren't creating version 3 blocks, BTCNuggets created a version 2 block which was invalid to all new clients (>=0.9.5) but valid to old clients. Antminer and F2Pool, comprising ~40% of the network at the time, were creating version 3 blocks, however neither miner validated previous blocks. This caused both Antminer and F2Pool to mine on top of BTCNuggets version 2 block and create an invalid fork. Over 40% of the hashpower was mining on this version 2 fork despite 95% having "agreed" to not do so. This led to a 6 block fork that was resolved after contacting the F2Pool and Antminer pool owners.<br />
<br />
Any SPV clients or out of date clients were vulnerable to these fake confirmations and in theory there could have been a reversed 6 confirmation transaction. Fortunately there were zero reversed confirmations and the only money lost was mining revenue that these pools lost. F2Pool has continued mining without validating beforehand and SPV client as well as outdated full node clients are at risk as long as they do so.<br />
<br />
==Implications==<br />
<br />
Softforks don't require any nodes to upgrade to maintain consensus since all blocks with the new softforked in rules also follow the old rules, therefore old clients accept them. Softforks cannot be reversed without a hardfork since a softfork by definition only allows the set of valid blocks to be a proper subset of what was valid pre-fork.<br />
<br />
If users upgrade to a post-softfork client and for some reason a majority of miners switch back to the pre-softfork client, the post-softfork client users would break consensus as soon as a block came along that didn't follow their clients new rules.<br />
<br />
See also: [[Hardfork]]</div>Lapp0https://en.bitcoin.it/w/index.php?title=Softfork&diff=57171Softfork2015-07-06T07:32:49Z<p>Lapp0: </p>
<hr />
<div>A softfork is a change to the bitcoin protocol wherein only previously valid blocks/transactions are made invalid.<br />
Since old nodes will recognise the new blocks as valid, a softfork is backward-compatible.<br />
This kind of fork requires only a majority of the miners upgrading to enforce the new rules.<br />
<br />
New transaction types can often be added as softforks, requiring only that the participants (sender and receiver) and miners understand the new transaction type.<br />
This is done by having the new transaction appear to older clients as a "pay-to-anybody" transaction (of a special form), and getting the miners to agree to reject blocks including these transaction unless the transaction validates under the new rules.<br />
This is how [[P2SH]] was added to Bitcoin.<br />
<br />
==Mechanism==<br />
<br />
Given a set of valid blocks, you can take any subset of those blocks and that subset will also, of course, all be valid. A softfork changes the rules such that only a subset of blocks that were previously valid remain so. Often softforks make certain transactions invalid, for example a softfork could make any transaction that is more than 1KB invalid (not that that would necessarily be desirable).<br />
<br />
Generally softforks accomplish something more useful, for example Pay-to-Script-Hash ([[P2SH]]) was a softfork. Originally the script "OP_HASH160 [20-byte-hash-value] OP_EQUAL" could be redeemed by simply pushing the preimage of the hashed value onto the stack. Now the value you push must be a script that evaluates to true. All new transactions with the script "OP_HASH160 [20-byte-hash-value] OP_EQUAL" weren't valid if they merely had a preimage of the hash pushed onto the stack, the preimage had to be a valid script. The requirement for the preimage being a valid script shrunk the set of valid transactions and added a feature at the same time.<br />
<br />
In the P2SH example, two opcodes were redefined so they had a new function. You can also add new opcodes that originally didn't do anything. Because the new rules must cause the set of valid blocks to be a proper subset of the valid blocks with the old rules, you must ensure that adding this new opcode doesn't cause transactions that were once invalid to be valid. In [[BIP12]] OP_EVAL is proposed. To softfork this new opcode in, the proposal stated an opcode that previously didn't have any effect would be replaced. The script would be evaluated twice, once with the opcode having the new OP_EVAL behavior and once with it's old behavior of doing nothing. The script being run with the old behavior of doing nothing would ensure that the transaction was valid to old clients.<br />
<br />
==Security==<br />
<br />
In order for a softfork to work, a majority of the mining power needs to be running a client recognizing the fork. The more miners you have, the more secure secure the network is postfork. If you have 3/4 of miners recognizing the fork, 1/4 blocks created aren't guaranteed to follow the new rules. These 1/4 blocks will be valid to old nodes that aren't aware of the new rules, but they will be ignored by new nodes. This allows a "fake confirmation" vulnerability, an attacker could create a transaction paying to their victim, but have it end up in a block not following new rules, they might bribe a miner to make the block incompatible with new rules or make the transaction itself incompatible. Because 3/4 the hashrate won't mine on top of the block, the block and the transaction paying to you will eventually not be in the "mainchain" allowing the attacker to attempt to doublespend.<br />
<br />
These attacks can be avoided by upgrading your client, however if the vast majority of miners (>95%) accept the new rules, the odds of an attacker being able to create many fake confirmations is low. Because miners want to make money, and without upgrading their blocks may be reorged out, there is an incentive for miners to upgrade and 100% acceptance of a fork should be achieved by miners quickly.<br />
<br />
==Implications==<br />
<br />
Softforks don't require any nodes to upgrade to maintain consensus since all blocks with the new softforked in rules also follow the old rules, therefore old clients accept them. Softforks cannot be reversed without a hardfork since a softfork by definition only allows the set of valid blocks to be a proper subset of what was valid pre-fork.<br />
<br />
If users upgrade to a post-softfork client and for some reason a majority of miners switch back to the pre-softfork client, the post-softfork client users would break consensus as soon as a block came along that didn't follow their clients new rules.<br />
<br />
See also: [[Hardfork]]</div>Lapp0https://en.bitcoin.it/w/index.php?title=Block_size_limit_controversy&diff=57156Block size limit controversy2015-07-05T01:40:35Z<p>Lapp0: /* Damage to decentralization */</p>
<hr />
<div>== Introduction ==<br />
<br />
Blocks are limited to 1MB in size. Miners can mine blocks upto the 1MB fixed limit. Any block larger than 1MB is invalid.<br />
<br />
The blocksize limit has the dual purpose of discouraging economically frivolous transactions from flooding the blockchain and encouraging transactions fees to incentivize miners.<br />
<br />
The fixed blocksize limit cannot be modified without a hard fork.<br />
<br />
Hard forks require adoption by virtually all of the bitcoin participants.<br />
<br />
== Arguments in favor of increasing the blocksize ==<br />
* More transactions per second<br />
<br />
== Unclear Arguments ==<br />
* Increased blocksize will leave space for extensibility like Mastercoin, Counterparty, etc.<br />
** Neutral: Bitcoin competitors will have lower fees<br />
** Negative: Bitcoin full nodes are forced to use more resources that don't support Bitcoin<br />
* Faster confirmation times with lower fees required<br />
** Positive: Bitcoin users pay lower fees<br />
** Negative: It will continue to be cheap to spam as companies like Satoshi Dice are already doing<br />
** Negative: Fees cannot be zero eventually in order to secure the mining ecosystem<br />
<br />
== Arguments in opposition to increasing the blocksize ==<br />
* A hard fork requires waiting for sufficient consensus.<br />
* However an emergency hard fork can achieve consensus for deployment on a short time period if needed.<br />
* Risk of catastrophic consensus failure<ref>https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html</ref><br />
* Orphan rate amplification, more reorgs and double-spends due to slower propagation speeds.<br />
* European/American pools at more of a disadvantage compared to the Chinese pools{{why}}<br />
* "Congestion" concerns can be solved with mempool improvements including transaction eviction.<br />
* No amount of max block size would support all the world's future transactions on the main blockchain (various types of off-chain transactions are the only long-term solution)<br />
* Fast block propagation is either not clearly viable, or (eg, IBLT) creates centralised controls.<br />
<br />
=== Damage to decentralization ===<br />
* Bitcoin is only useful if it is decentralized because centralization requires trust. Bitcoins value proposition is trustlessness.<br />
* The larger the hash-rate a single miner controls, the more centralized Bitcoin becomes and the more trust using Bitcoin requires.<br />
* Running your own full node while mining rather than giving another entity the right to your hash-power decreases the hash-rate of large miners. Those who have hash-power are able to control their own hash power if and only if they run a full node.<br />
* Less individuals who control hash-power will run full nodes if running one becomes more expensive<ref>https://www.weusecoins.com/why-blocksize-limit-keeps-bitcoin-free-decentralized/</ref>.<br />
* Larger blocks leads to more expensive full nodes.<br />
* Therefore, larger blocks lead to less hashers running full nodes, which leads to centralized entities having more power, which makes Bitcoin require more trust, which weakens Bitcoins value proposition.<br />
<br />
== Entities positions ==<br />
Positions below are based on a suggested fixed block size increase to 20MiB. Positions against these larger blocks do not necessarily imply that they are against an increase in general, and may instead support a smaller and/or gradual increase.<br />
{| class="wikitable sortable"<br />
! Entity<br />
! Supports Larger Blocks<br />
! Supports Hard Fork<br />
|-<br />
| Bitcoinpaygate<br />
| {{No|No: "We do NOT support the blocksize increase"}}<ref>http://www.reddit.com/r/Bitcoin/comments/37y8wm/list_of_bitcoin_services_that_supportoppose/crqsnqp</ref><br />
|<br />
|-<br />
| Bitrated<br />
| {{No}}<br />"At this time, I oppose increasing the block size limit as per Gavin's proposal" - Nadav Ivgi (founder)<ref>https://twitter.com/shesek/status/605005384026177537</ref><br />
|<br />
|-<br />
| [[F2Pool]]<br />
| {{No|No: "We do support bigger blocks and sooner rather than later. But we cannot handle 20 MB blocks right now. ... I think we can accept 5MB block at most."}}<ref>http://sourceforge.net/p/bitcoin/mailman/message/34157036/],[http://sourceforge.net/p/bitcoin/mailman/message/34158911/</ref><br />
|<br />
|-<br />
| [[GreenAddress]]<br />
| {{No|No: "In our mind increasing the block size like this is just pushing the problem a little further at potentially unfixable costs."}}<ref>http://www.reddit.com/r/Bitcoin/comments/35anax/list_of_bitcoin_services_that_support_increasing/cr2mq84</ref><br />
|<br />
|-<br />
| [[MPEx]]<br />
| {{No}}<ref>http://log.bitcoin-assets.com//?date=07-01-2015#967332</ref><br />
|<br />
|-<br />
| [[Paymium]]<br />
| {{No|No: "<nowiki>[allow]</nowiki> a sane transaction fee market to emerge, by letting the blocks actually fill-up."}} - CTO David Francois<ref>http://fr.anco.is/2015/gavineries/</ref><br />
| <br />
|-<br />
| Ethereum<br /><br />
| {{Neutral|Neutral: "If <nowiki>[the niche of digital gold]</nowiki> is what Bitcoin users want, then they should keep the limit, and perhaps even decrease it. But if Bitcoin users want to be a payment system, then up it must go."}} - Vitalik Buterin (founder)<ref>http://www.reddit.com/r/ethereum/comments/380q61/i_know_this_may_not_directly_be_ethereum_related/crrofl6</ref><br />
|<br />
|-<br />
| [[Armory]]<br />
| {{Yes}}<br />"This *is* urgent and needs to be handled right now, and I believe Gavin<br />
has the best approach to this." - CEO Alan Reiner<ref>http://sourceforge.net/p/bitcoin/mailman/message/34093337/</ref><br />
|<br />
|-<br />
| BitcoinReminder<br />
| {{Yes|Yes: "BitcoinReminder.com also supports 20MB blocks (or even more?"}}<ref>http://www.reddit.com/r/Bitcoin/comments/37y8wm/list_of_bitcoin_services_that_supportoppose/crs9ytd</ref><br />
|<br />
|-<br />
| BitHours<br />
| {{Yes|Yes: "We support @gavinandresen and his proposal for 20mb blocks"}}<ref>https://twitter.com/bithours/status/605131647747358721</ref><br />
|<br />
|-<br />
| [[BitPay]]<br />
| {{Yes}}<br />"Agreed (but optimistic this will be the last and only time block size needs to increase)" - CEO Stephen Pair<ref>https://twitter.com/spair/status/595341090317799424</ref><br />
| <br />
|-<br />
| Bittiraha.fi<br />
| {{Yes|Yes: "We are supporting increasing #Bitcoin max block size to 20MB."}}<ref>https://twitter.com/Bittirahafi/status/596682373028311040</ref><br />"I'm strongly in favor of the block size cap increase to 20MB." - CEO Henry Brade<ref>https://twitter.com/Technom4ge/status/596334370803326978</ref><br />
| {{Yes}}<br />"And I'm in favor of releasing a version with this change even with opposition." - CEO Henry Brade<ref>https://twitter.com/Technom4ge/status/596334370803326978</ref><br />
|-<br />
| [[Blockchain.info]]<br />
|{{Yes}}<br />"It is time to increase the block size. Agree with @gavinandresen" - CEO Peter Smith<ref>https://twitter.com/OneMorePeter/status/595676380320407553</ref><br />"Scaling #bitcoin is a big deal. Increase the block size." - Nic Cary<ref>https://twitter.com/niccary/status/595707211994763264</ref><br />
|<br />
|-<br />
| Breadwallet<br />
| {{Yes}}<br />"[...] in support of the Gavin's 20Mb block proposal." - CEO Aaron Voisine<ref>http://sourceforge.net/p/bitcoin/mailman/message/34096857/</ref><br />
|<br />
|-<br />
| [[BTC Guild]]<br />
| {{Yes}}<br />"Needs to happen, but needs future expansion built in at a reasonable rate." - Eleuthria<ref>https://www.reddit.com/r/Bitcoin/comments/370rko/21_inc_engineer_everyone_assumes_humans_will_be/crjfnpg?context=3</ref><br />
|<br />
|-<br />
| BX.in.th<br />
| {{Yes|Yes: "<nowiki>http://BX.in.th</nowiki> will support the 20MB block size"}}<ref>https://twitter.com/BitcoinThai/status/605022509101023232</ref><br />
| <br />
|- <br />
| [[Coinbase (business)|CoinBase]]<br />
| {{Yes|Yes: "Coinbase supports increasing the maximum block size"}}<ref>https://twitter.com/coinbase/status/595741967759335426</ref><br />"Why we should increase the block size" - CEO Brian Armstrong<ref>https://twitter.com/brian_armstrong/status/595453245884997634</ref><br />
|<br />
|- <br />
| [[Dr. Adam Back (individual)|Dr. Adam Back]]<br />
| {{Yes|Yes: "For the record I am not aware of a single person who has said they do not agree with scaling Bitcoin. Changing a constant is not the hard-part. The hard part is validating a plan and the other factors that go into it. It's not a free choice it is a security/scalability tradeoff. No one will thank us if we "scale" bitcoin but break it in hard to recover ways at the same time."}} <ref>https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html</ref><br />
| {{No}}<br />"I strongly urge that we return to the existing collaborative constructive review process that has been used for the last 4 years which is a consensus by design to prevent one rogue person from inserting a backdoor, or lobbying for a favoured change on behalf of a special interest group, or working for bad actor" - Dr. Adam Back<ref>https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html</ref><br />
|<br />
|-<br />
| Kryptoradio<br />
| {{Yes}}<br />"#Kryptoradio dev @zouppen supports 20MB block size in #bitcoin." - Joel Lehtonen<ref>https://twitter.com/koodilehto/status/596675967667568641</ref><br />
|<br />
|- <br />
| OKCoin<br />
| {{Yes|Yes: "OKCoin's tech team believes it's the right decision"}}<ref>https://twitter.com/okcoinbtc/status/598412795240009728</ref><br />
|<br />
|-<br />
| Third Key Solutions<br />
| {{Yes}}<br />"Gavin is right. The time to increase the block size limit is before transaction processing shows congestion problems." - CTO Andreas Antonopoulos<ref>https://twitter.com/aantonop/status/595601619581964289</ref><br />
|<br />
|-<br />
| Xapo<br />
| {{Yes|Yes: "One meg is not enough: Xapo supports increasing the maximum block size"}} - CEO Wences Casares<ref>https://twitter.com/wences/status/595768917907402752</ref><br />
|<br />
|}</div>Lapp0https://en.bitcoin.it/w/index.php?title=Block_size_limit_controversy&diff=57087Block size limit controversy2015-06-27T09:01:14Z<p>Lapp0: </p>
<hr />
<div>== Introduction ==<br />
<br />
Blocks are limited to 1MB in size. Miners can mine blocks upto the 1MB fixed limit. Any block larger than 1MB is invalid.<br />
<br />
The blocksize limit has the dual purpose of discouraging economically frivolous transactions from flooding the blockchain and encouraging transactions fees to incentivize miners.<br />
<br />
The fixed blocksize limit cannot be modified without a hard fork.<br />
<br />
Hard forks require adoption by virtually all of the bitcoin participants.<br />
<br />
== Arguments in favor of increasing the blocksize ==<br />
* More transactions per second<br />
<br />
== Unclear Arguments ==<br />
* Increased blocksize will leave space for extensibility like Mastercoin, Counterparty, etc.<br />
** Neutral: Bitcoin competitors will have lower fees<br />
** Negative: Bitcoin full nodes are forced to use more resources that don't support Bitcoin<br />
* Faster confirmation times with lower fees required<br />
** Positive: Bitcoin users pay lower fees<br />
** Negative: It will continue to be cheap to spam as companies like Satoshi Dice are already doing<br />
** Negative: Fees cannot be zero eventually in order to secure the mining ecosystem<br />
<br />
== Arguments in opposition to increasing the blocksize ==<br />
* A hard fork requires waiting for sufficient consensus.<br />
* However an emergency hard fork can achieve consensus for deployment on a short time period if needed.<br />
* Risk of catastrophic consensus failure<ref>https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html</ref><br />
* Orphan rate amplification, more reorgs and double-spends due to slower propagation speeds.<br />
* European/American pools at more of a disadvantage compared to the Chinese pools{{why}}<br />
* "Congestion" concerns can be solved with mempool improvements including transaction eviction.<br />
* No amount of max block size would support all the world's future transactions on the main blockchain (various types of off-chain transactions are the only long-term solution)<br />
* Fast block propagation is either not clearly viable, or (eg, IBLT) creates centralised controls.<br />
<br />
=== Damage to decentalization ===<br />
* Bitcoin is only useful if it is decentralized because centralization requires trust. Bitcoins value proposition is trustlessness.<br />
* The larger the hash-rate a single miner controls, the more centralized Bitcoin becomes and the more trust using Bitcoin requires.<br />
* Running your own full node while mining rather than giving another entity the right to your hash-power decreases the hash-rate of large miners. Those who control hash-power are able to control their own hash power if and only if they run a full node.<br />
* Less individuals who control hash-power will run full nodes if running one becomes more expensive<ref>https://www.weusecoins.com/why-blocksize-limit-keeps-bitcoin-free-decentralized/</ref>.<br />
* Larger blocks leads to more expensive full nodes.<br />
* Therefore, larger blocks lead to less hashers running full nodes, which leads to centralized entities having more power, which makes Bitcoin require more trust, which weakens Bitcoins value proposition.<br />
<br />
== Entities positions ==<br />
Positions below are based on a suggested fixed block size increase to 20MiB. Positions against these larger blocks do not necessarily imply that they are against an increase in general, and may instead support a smaller and/or gradual increase.<br />
{| class="wikitable sortable"<br />
! Entity<br />
! Supports Larger Blocks<br />
! Supports Hard Fork<br />
|-<br />
| Bitcoinpaygate<br />
| {{No|No: "We do NOT support the blocksize increase"}}<ref>http://www.reddit.com/r/Bitcoin/comments/37y8wm/list_of_bitcoin_services_that_supportoppose/crqsnqp</ref><br />
|<br />
|-<br />
| Bitrated<br />
| {{No}}<br />"At this time, I oppose increasing the block size limit as per Gavin's proposal" - Nadav Ivgi (founder)<ref>https://twitter.com/shesek/status/605005384026177537</ref><br />
|<br />
|-<br />
| [[F2Pool]]<br />
| {{No|No: "We do support bigger blocks and sooner rather than later. But we cannot handle 20 MB blocks right now. ... I think we can accept 5MB block at most."}}<ref>http://sourceforge.net/p/bitcoin/mailman/message/34157036/],[http://sourceforge.net/p/bitcoin/mailman/message/34158911/</ref><br />
|<br />
|-<br />
| [[GreenAddress]]<br />
| {{No|No: "In our mind increasing the block size like this is just pushing the problem a little further at potentially unfixable costs."}}<ref>http://www.reddit.com/r/Bitcoin/comments/35anax/list_of_bitcoin_services_that_support_increasing/cr2mq84</ref><br />
|<br />
|-<br />
| [[MPEx]]<br />
| {{No}}<ref>http://log.bitcoin-assets.com//?date=07-01-2015#967332</ref><br />
|<br />
|-<br />
| [[Paymium]]<br />
| {{No|No: "<nowiki>[allow]</nowiki> a sane transaction fee market to emerge, by letting the blocks actually fill-up."}} - CTO David Francois<ref>http://fr.anco.is/2015/gavineries/</ref><br />
| <br />
|-<br />
| Ethereum<br /><br />
| {{Neutral|Neutral: "If <nowiki>[the niche of digital gold]</nowiki> is what Bitcoin users want, then they should keep the limit, and perhaps even decrease it. But if Bitcoin users want to be a payment system, then up it must go."}} - Vitalik Buterin (founder)<ref>http://www.reddit.com/r/ethereum/comments/380q61/i_know_this_may_not_directly_be_ethereum_related/crrofl6</ref><br />
|<br />
|-<br />
| [[Armory]]<br />
| {{Yes}}<br />"This *is* urgent and needs to be handled right now, and I believe Gavin<br />
has the best approach to this." - CEO Alan Reiner<ref>http://sourceforge.net/p/bitcoin/mailman/message/34093337/</ref><br />
|<br />
|-<br />
| BitcoinReminder<br />
| {{Yes|Yes: "BitcoinReminder.com also supports 20MB blocks (or even more?"}}<ref>http://www.reddit.com/r/Bitcoin/comments/37y8wm/list_of_bitcoin_services_that_supportoppose/crs9ytd</ref><br />
|<br />
|-<br />
| BitHours<br />
| {{Yes|Yes: "We support @gavinandresen and his proposal for 20mb blocks"}}<ref>https://twitter.com/bithours/status/605131647747358721</ref><br />
|<br />
|-<br />
| [[BitPay]]<br />
| {{Yes}}<br />"Agreed (but optimistic this will be the last and only time block size needs to increase)" - CEO Stephen Pair<ref>https://twitter.com/spair/status/595341090317799424</ref><br />
| <br />
|-<br />
| Bittiraha.fi<br />
| {{Yes|Yes: "We are supporting increasing #Bitcoin max block size to 20MB."}}<ref>https://twitter.com/Bittirahafi/status/596682373028311040</ref><br />"I'm strongly in favor of the block size cap increase to 20MB." - CEO Henry Brade<ref>https://twitter.com/Technom4ge/status/596334370803326978</ref><br />
| {{Yes}}<br />"And I'm in favor of releasing a version with this change even with opposition." - CEO Henry Brade<ref>https://twitter.com/Technom4ge/status/596334370803326978</ref><br />
|-<br />
| [[Blockchain.info]]<br />
|{{Yes}}<br />"It is time to increase the block size. Agree with @gavinandresen" - CEO Peter Smith<ref>https://twitter.com/OneMorePeter/status/595676380320407553</ref><br />"Scaling #bitcoin is a big deal. Increase the block size." - Nic Cary<ref>https://twitter.com/niccary/status/595707211994763264</ref><br />
|<br />
|-<br />
| Breadwallet<br />
| {{Yes}}<br />"[...] in support of the Gavin's 20Mb block proposal." - CEO Aaron Voisine<ref>http://sourceforge.net/p/bitcoin/mailman/message/34096857/</ref><br />
|<br />
|-<br />
| [[BTC Guild]]<br />
| {{Yes}}<br />"Needs to happen, but needs future expansion built in at a reasonable rate." - Eleuthria<ref>https://www.reddit.com/r/Bitcoin/comments/370rko/21_inc_engineer_everyone_assumes_humans_will_be/crjfnpg?context=3</ref><br />
|<br />
|-<br />
| BX.in.th<br />
| {{Yes|Yes: "<nowiki>http://BX.in.th</nowiki> will support the 20MB block size"}}<ref>https://twitter.com/BitcoinThai/status/605022509101023232</ref><br />
| <br />
|- <br />
| [[Coinbase (business)|CoinBase]]<br />
| {{Yes|Yes: "Coinbase supports increasing the maximum block size"}}<ref>https://twitter.com/coinbase/status/595741967759335426</ref><br />"Why we should increase the block size" - CEO Brian Armstrong<ref>https://twitter.com/brian_armstrong/status/595453245884997634</ref><br />
|<br />
|- <br />
| [[Dr. Adam Back (individual)|Dr. Adam Back]]<br />
| {{Yes|Yes: "For the record I am not aware of a single person who has said they do not agree with scaling Bitcoin. Changing a constant is not the hard-part. The hard part is validating a plan and the other factors that go into it. It's not a free choice it is a security/scalability tradeoff. No one will thank us if we "scale" bitcoin but break it in hard to recover ways at the same time."}} <ref>https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html</ref><br />
| {{No}}<br />"I strongly urge that we return to the existing collaborative constructive review process that has been used for the last 4 years which is a consensus by design to prevent one rogue person from inserting a backdoor, or lobbying for a favoured change on behalf of a special interest group, or working for bad actor" - Dr. Adam Back<ref>https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html</ref><br />
|<br />
|-<br />
| Kryptoradio<br />
| {{Yes}}<br />"#Kryptoradio dev @zouppen supports 20MB block size in #bitcoin." - Joel Lehtonen<ref>https://twitter.com/koodilehto/status/596675967667568641</ref><br />
|<br />
|- <br />
| OKCoin<br />
| {{Yes|Yes: "OKCoin's tech team believes it's the right decision"}}<ref>https://twitter.com/okcoinbtc/status/598412795240009728</ref><br />
|<br />
|-<br />
| Third Key Solutions<br />
| {{Yes}}<br />"Gavin is right. The time to increase the block size limit is before transaction processing shows congestion problems." - CTO Andreas Antonopoulos<ref>https://twitter.com/aantonop/status/595601619581964289</ref><br />
|<br />
|-<br />
| Xapo<br />
| {{Yes|Yes: "One meg is not enough: Xapo supports increasing the maximum block size"}} - CEO Wences Casares<ref>https://twitter.com/wences/status/595768917907402752</ref><br />
|<br />
|}</div>Lapp0https://en.bitcoin.it/w/index.php?title=Block_size_limit_controversy&diff=57017Block size limit controversy2015-06-17T18:02:55Z<p>Lapp0: Probably should be its own section</p>
<hr />
<div>== Introduction ==<br />
<br />
Blocks are limited to 1MB in size. Miners can mine blocks upto the 1MB fixed limit. Any block larger than 1MB is invalid.<br />
<br />
The blocksize limit has the dual purpose of discouraging economically frivolous transactions from flooding the blockchain and encouraging transactions fees to incentivize miners.<br />
<br />
The fixed blocksize limit cannot be modified without a hard fork.<br />
<br />
Hard forks require adoption by virtually all of the bitcoin participants.<br />
<br />
== Arguments in favor of increasing the blocksize ==<br />
* More transactions per second<br />
<br />
== Unclear Arguments ==<br />
* Increased blocksize will leave space for extensibility like Mastercoin, Counterparty, etc.<br />
** Neutral: Bitcoin competitors will have lower fees<br />
** Negative: Bitcoin full nodes are forced to use more resources that don't support Bitcoin<br />
* Faster confirmation times with lower fees required<br />
** Positive: Bitcoin users pay lower fees<br />
** Negative: It will continue to be cheap to spam as companies like Satoshi Dice are already doing<br />
** Negative: Fees cannot be zero eventually in order to secure the mining ecosystem<br />
<br />
== Arguments in opposition to increasing the blocksize ==<br />
* A hard fork requires waiting for sufficient consensus.<br />
* However an emergency hard fork can achieve consensus for deployment on a short time period if needed.<br />
* Risk of catastrophic consensus failure<ref>https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html</ref><br />
* Orphan rate amplification, more reorgs and double-spends due to slower propagation speeds.<br />
* European/American pools at more of a disadvantage compared to the Chinese pools{{why}}<br />
* No amount of max block size would support all the world's future transactions on the main blockchain (various types of off-chain transactions are the only long-term solution)<br />
* Fast block propagation is either not clearly viable, or (eg, IBLT) creates centralised controls.<br />
<br />
=== Damage to decentalization ===<br />
* Bitcoin is only useful if it is decentralized because centralization requires trust. Bitcoins value proposition is trustlessness.<br />
* The larger the hash-rate a single miner controls, the more centralized Bitcoin becomes and the more trust using Bitcoin requires.<br />
* Running your own full node while mining rather than giving another entity the right to your hash-power decreases the hash-rate of large miners. Those who control hash-power are able to control their own hash power if and only if they run a full node.<br />
* Less individuals who control hash-power will run full nodes if running one becomes more expensive<ref>https://www.weusecoins.com/why-blocksize-limit-keeps-bitcoin-free-decentralized/</ref>.<br />
* Larger blocks leads to more expensive full nodes.<br />
* Therefore, larger blocks lead to less hashers running full nodes, which leads to centralized entities having more power, which makes Bitcoin require more trust, which weakens Bitcoins value proposition.<br />
<br />
== Entities positions ==<br />
Positions below are based on a suggested fixed block size increase to 20MiB. Positions against these larger blocks do not necessarily imply that they are against an increase in general, and may instead support a smaller and/or gradual increase.<br />
{| class="wikitable sortable"<br />
! Entity<br />
! Supports Larger Blocks<br />
! Supports Hard Fork<br />
|-<br />
| Bitcoinpaygate<br />
| {{No|No: "We do NOT support the blocksize increase"}}<ref>http://www.reddit.com/r/Bitcoin/comments/37y8wm/list_of_bitcoin_services_that_supportoppose/crqsnqp</ref><br />
|<br />
|-<br />
| Bitrated<br />
| {{No}}<br />"At this time, I oppose increasing the block size limit as per Gavin's proposal" - Nadav Ivgi (founder)<ref>https://twitter.com/shesek/status/605005384026177537</ref><br />
|<br />
|-<br />
| [[F2Pool]]<br />
| {{No|No: "We do support bigger blocks and sooner rather than later. But we cannot handle 20 MB blocks right now. ... I think we can accept 5MB block at most."}}<ref>http://sourceforge.net/p/bitcoin/mailman/message/34157036/],[http://sourceforge.net/p/bitcoin/mailman/message/34158911/</ref><br />
|<br />
|-<br />
| [[GreenAddress]]<br />
| {{No|No: "In our mind increasing the block size like this is just pushing the problem a little further at potentially unfixable costs."}}<ref>http://www.reddit.com/r/Bitcoin/comments/35anax/list_of_bitcoin_services_that_support_increasing/cr2mq84</ref><br />
|<br />
|-<br />
| [[MPEx]]<br />
| {{No}}<ref>http://log.bitcoin-assets.com//?date=07-01-2015#967332</ref><br />
|<br />
|-<br />
| [[Paymium]]<br />
| {{No|No: "<nowiki>[allow]</nowiki> a sane transaction fee market to emerge, by letting the blocks actually fill-up."}} - CTO David Francois<ref>http://fr.anco.is/2015/gavineries/</ref><br />
| <br />
|-<br />
| Ethereum<br /><br />
| {{Neutral|Neutral: "If <nowiki>[the niche of digital gold]</nowiki> is what Bitcoin users want, then they should keep the limit, and perhaps even decrease it. But if Bitcoin users want to be a payment system, then up it must go."}} - Vitalik Buterin (founder)<ref>http://www.reddit.com/r/ethereum/comments/380q61/i_know_this_may_not_directly_be_ethereum_related/crrofl6</ref><br />
|<br />
|-<br />
| [[Armory]]<br />
| {{Yes}}<br />"This *is* urgent and needs to be handled right now, and I believe Gavin<br />
has the best approach to this." - CEO Alan Reiner<ref>http://sourceforge.net/p/bitcoin/mailman/message/34093337/</ref><br />
|<br />
|-<br />
| BitcoinReminder<br />
| {{Yes|Yes: "BitcoinReminder.com also supports 20MB blocks (or even more?"}}<ref>http://www.reddit.com/r/Bitcoin/comments/37y8wm/list_of_bitcoin_services_that_supportoppose/crs9ytd</ref><br />
|<br />
|-<br />
| BitHours<br />
| {{Yes|Yes: "We support @gavinandresen and his proposal for 20mb blocks"}}<ref>https://twitter.com/bithours/status/605131647747358721</ref><br />
|<br />
|-<br />
| [[BitPay]]<br />
| {{Yes}}<br />"Agreed (but optimistic this will be the last and only time block size needs to increase)" - CEO Stephen Pair<ref>https://twitter.com/spair/status/595341090317799424</ref><br />
| <br />
|-<br />
| Bittiraha.fi<br />
| {{Yes|Yes: "We are supporting increasing #Bitcoin max block size to 20MB."}}<ref>https://twitter.com/Bittirahafi/status/596682373028311040</ref><br />"I'm strongly in favor of the block size cap increase to 20MB." - CEO Henry Brade<ref>https://twitter.com/Technom4ge/status/596334370803326978</ref><br />
| {{Yes}}<br />"And I'm in favor of releasing a version with this change even with opposition." - CEO Henry Brade<ref>https://twitter.com/Technom4ge/status/596334370803326978</ref><br />
|-<br />
| [[Blockchain.info]]<br />
|{{Yes}}<br />"It is time to increase the block size. Agree with @gavinandresen" - CEO Peter Smith<ref>https://twitter.com/OneMorePeter/status/595676380320407553</ref><br />"Scaling #bitcoin is a big deal. Increase the block size." - Nic Cary<ref>https://twitter.com/niccary/status/595707211994763264</ref><br />
|<br />
|-<br />
| Breadwallet<br />
| {{Yes}}<br />"[...] in support of the Gavin's 20Mb block proposal." - CEO Aaron Voisine<ref>http://sourceforge.net/p/bitcoin/mailman/message/34096857/</ref><br />
|<br />
|-<br />
| [[BTC Guild]]<br />
| {{Yes}}<br />"Needs to happen, but needs future expansion built in at a reasonable rate." - Eleuthria<ref>https://www.reddit.com/r/Bitcoin/comments/370rko/21_inc_engineer_everyone_assumes_humans_will_be/crjfnpg?context=3</ref><br />
|<br />
|-<br />
| BX.in.th<br />
| {{Yes|Yes: "<nowiki>http://BX.in.th</nowiki> will support the 20MB block size"}}<ref>https://twitter.com/BitcoinThai/status/605022509101023232</ref><br />
| <br />
|- <br />
| [[Coinbase (business)|CoinBase]]<br />
| {{Yes|Yes: "Coinbase supports increasing the maximum block size"}}<ref>https://twitter.com/coinbase/status/595741967759335426</ref><br />"Why we should increase the block size" - CEO Brian Armstrong<ref>https://twitter.com/brian_armstrong/status/595453245884997634</ref><br />
|<br />
|- <br />
| [[Dr. Adam Back (individual)|Dr. Adam Back]]<br />
| {{Yes|Yes: "For the record I am not aware of a single person who has said they do not agree with scaling Bitcoin. Changing a constant is not the hard-part. The hard part is validating a plan and the other factors that go into it. It's not a free choice it is a security/scalability tradeoff. No one will thank us if we "scale" bitcoin but break it in hard to recover ways at the same time."}} <ref>https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html</ref><br />
| {{No}}<br />"I strongly urge that we return to the existing collaborative constructive review process that has been used for the last 4 years which is a consensus by design to prevent one rogue person from inserting a backdoor, or lobbying for a favoured change on behalf of a special interest group, or working for bad actor" - Dr. Adam Back<ref>https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html</ref><br />
|<br />
|-<br />
| Kryptoradio<br />
| {{Yes}}<br />"#Kryptoradio dev @zouppen supports 20MB block size in #bitcoin." - Joel Lehtonen<ref>https://twitter.com/koodilehto/status/596675967667568641</ref><br />
|<br />
|- <br />
| OKCoin<br />
| {{Yes|Yes: "OKCoin's tech team believes it's the right decision"}}<ref>https://twitter.com/okcoinbtc/status/598412795240009728</ref><br />
|<br />
|-<br />
| Third Key Solutions<br />
| {{Yes}}<br />"Gavin is right. The time to increase the block size limit is before transaction processing shows congestion problems." - CTO Andreas Antonopoulos<ref>https://twitter.com/aantonop/status/595601619581964289</ref><br />
|<br />
|-<br />
| Xapo<br />
| {{Yes|Yes: "One meg is not enough: Xapo supports increasing the maximum block size"}} - CEO Wences Casares<ref>https://twitter.com/wences/status/595768917907402752</ref><br />
|<br />
|}</div>Lapp0https://en.bitcoin.it/w/index.php?title=Block_size_limit_controversy&diff=57016Block size limit controversy2015-06-17T18:01:43Z<p>Lapp0: removed SNARKS because they don't require a blocksize increase, added unclear arguments section, moved some notes there</p>
<hr />
<div>== Introduction ==<br />
<br />
Blocks are limited to 1MB in size. Miners can mine blocks upto the 1MB fixed limit. Any block larger than 1MB is invalid.<br />
<br />
The blocksize limit has the dual purpose of discouraging economically frivolous transactions from flooding the blockchain and encouraging transactions fees to incentivize miners.<br />
<br />
The fixed blocksize limit cannot be modified without a hard fork.<br />
<br />
Hard forks require adoption by virtually all of the bitcoin participants.<br />
<br />
== Arguments in favor of increasing the blocksize ==<br />
* More transactions per second<br />
<br />
=== Unclear Arguments ===<br />
* Increased blocksize will leave space for extensibility like Mastercoin, Counterparty, etc.<br />
** Neutral: Bitcoin competitors will have lower fees<br />
** Negative: Bitcoin full nodes are forced to use more resources that don't support Bitcoin<br />
* Faster confirmation times with lower fees required<br />
** Positive: Bitcoin users pay lower fees<br />
** Negative: It will continue to be cheap to spam as companies like Satoshi Dice are already doing<br />
** Negative: Fees cannot be zero eventually in order to secure the mining ecosystem<br />
<br />
== Arguments in opposition to increasing the blocksize ==<br />
* A hard fork requires waiting for sufficient consensus.<br />
* However an emergency hard fork can achieve consensus for deployment on a short time period if needed.<br />
* Risk of catastrophic consensus failure<ref>https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html</ref><br />
* Orphan rate amplification, more reorgs and double-spends due to slower propagation speeds.<br />
* European/American pools at more of a disadvantage compared to the Chinese pools{{why}}<br />
* No amount of max block size would support all the world's future transactions on the main blockchain (various types of off-chain transactions are the only long-term solution)<br />
* Fast block propagation is either not clearly viable, or (eg, IBLT) creates centralised controls.<br />
<br />
=== Damage to decentalization ===<br />
* Bitcoin is only useful if it is decentralized because centralization requires trust. Bitcoins value proposition is trustlessness.<br />
* The larger the hash-rate a single miner controls, the more centralized Bitcoin becomes and the more trust using Bitcoin requires.<br />
* Running your own full node while mining rather than giving another entity the right to your hash-power decreases the hash-rate of large miners. Those who control hash-power are able to control their own hash power if and only if they run a full node.<br />
* Less individuals who control hash-power will run full nodes if running one becomes more expensive<ref>https://www.weusecoins.com/why-blocksize-limit-keeps-bitcoin-free-decentralized/</ref>.<br />
* Larger blocks leads to more expensive full nodes.<br />
* Therefore, larger blocks lead to less hashers running full nodes, which leads to centralized entities having more power, which makes Bitcoin require more trust, which weakens Bitcoins value proposition.<br />
<br />
== Entities positions ==<br />
Positions below are based on a suggested fixed block size increase to 20MiB. Positions against these larger blocks do not necessarily imply that they are against an increase in general, and may instead support a smaller and/or gradual increase.<br />
{| class="wikitable sortable"<br />
! Entity<br />
! Supports Larger Blocks<br />
! Supports Hard Fork<br />
|-<br />
| Bitcoinpaygate<br />
| {{No|No: "We do NOT support the blocksize increase"}}<ref>http://www.reddit.com/r/Bitcoin/comments/37y8wm/list_of_bitcoin_services_that_supportoppose/crqsnqp</ref><br />
|<br />
|-<br />
| Bitrated<br />
| {{No}}<br />"At this time, I oppose increasing the block size limit as per Gavin's proposal" - Nadav Ivgi (founder)<ref>https://twitter.com/shesek/status/605005384026177537</ref><br />
|<br />
|-<br />
| [[F2Pool]]<br />
| {{No|No: "We do support bigger blocks and sooner rather than later. But we cannot handle 20 MB blocks right now. ... I think we can accept 5MB block at most."}}<ref>http://sourceforge.net/p/bitcoin/mailman/message/34157036/],[http://sourceforge.net/p/bitcoin/mailman/message/34158911/</ref><br />
|<br />
|-<br />
| [[GreenAddress]]<br />
| {{No|No: "In our mind increasing the block size like this is just pushing the problem a little further at potentially unfixable costs."}}<ref>http://www.reddit.com/r/Bitcoin/comments/35anax/list_of_bitcoin_services_that_support_increasing/cr2mq84</ref><br />
|<br />
|-<br />
| [[MPEx]]<br />
| {{No}}<ref>http://log.bitcoin-assets.com//?date=07-01-2015#967332</ref><br />
|<br />
|-<br />
| [[Paymium]]<br />
| {{No|No: "<nowiki>[allow]</nowiki> a sane transaction fee market to emerge, by letting the blocks actually fill-up."}} - CTO David Francois<ref>http://fr.anco.is/2015/gavineries/</ref><br />
| <br />
|-<br />
| Ethereum<br /><br />
| {{Neutral|Neutral: "If <nowiki>[the niche of digital gold]</nowiki> is what Bitcoin users want, then they should keep the limit, and perhaps even decrease it. But if Bitcoin users want to be a payment system, then up it must go."}} - Vitalik Buterin (founder)<ref>http://www.reddit.com/r/ethereum/comments/380q61/i_know_this_may_not_directly_be_ethereum_related/crrofl6</ref><br />
|<br />
|-<br />
| [[Armory]]<br />
| {{Yes}}<br />"This *is* urgent and needs to be handled right now, and I believe Gavin<br />
has the best approach to this." - CEO Alan Reiner<ref>http://sourceforge.net/p/bitcoin/mailman/message/34093337/</ref><br />
|<br />
|-<br />
| BitcoinReminder<br />
| {{Yes|Yes: "BitcoinReminder.com also supports 20MB blocks (or even more?"}}<ref>http://www.reddit.com/r/Bitcoin/comments/37y8wm/list_of_bitcoin_services_that_supportoppose/crs9ytd</ref><br />
|<br />
|-<br />
| BitHours<br />
| {{Yes|Yes: "We support @gavinandresen and his proposal for 20mb blocks"}}<ref>https://twitter.com/bithours/status/605131647747358721</ref><br />
|<br />
|-<br />
| [[BitPay]]<br />
| {{Yes}}<br />"Agreed (but optimistic this will be the last and only time block size needs to increase)" - CEO Stephen Pair<ref>https://twitter.com/spair/status/595341090317799424</ref><br />
| <br />
|-<br />
| Bittiraha.fi<br />
| {{Yes|Yes: "We are supporting increasing #Bitcoin max block size to 20MB."}}<ref>https://twitter.com/Bittirahafi/status/596682373028311040</ref><br />"I'm strongly in favor of the block size cap increase to 20MB." - CEO Henry Brade<ref>https://twitter.com/Technom4ge/status/596334370803326978</ref><br />
| {{Yes}}<br />"And I'm in favor of releasing a version with this change even with opposition." - CEO Henry Brade<ref>https://twitter.com/Technom4ge/status/596334370803326978</ref><br />
|-<br />
| [[Blockchain.info]]<br />
|{{Yes}}<br />"It is time to increase the block size. Agree with @gavinandresen" - CEO Peter Smith<ref>https://twitter.com/OneMorePeter/status/595676380320407553</ref><br />"Scaling #bitcoin is a big deal. Increase the block size." - Nic Cary<ref>https://twitter.com/niccary/status/595707211994763264</ref><br />
|<br />
|-<br />
| Breadwallet<br />
| {{Yes}}<br />"[...] in support of the Gavin's 20Mb block proposal." - CEO Aaron Voisine<ref>http://sourceforge.net/p/bitcoin/mailman/message/34096857/</ref><br />
|<br />
|-<br />
| [[BTC Guild]]<br />
| {{Yes}}<br />"Needs to happen, but needs future expansion built in at a reasonable rate." - Eleuthria<ref>https://www.reddit.com/r/Bitcoin/comments/370rko/21_inc_engineer_everyone_assumes_humans_will_be/crjfnpg?context=3</ref><br />
|<br />
|-<br />
| BX.in.th<br />
| {{Yes|Yes: "<nowiki>http://BX.in.th</nowiki> will support the 20MB block size"}}<ref>https://twitter.com/BitcoinThai/status/605022509101023232</ref><br />
| <br />
|- <br />
| [[Coinbase (business)|CoinBase]]<br />
| {{Yes|Yes: "Coinbase supports increasing the maximum block size"}}<ref>https://twitter.com/coinbase/status/595741967759335426</ref><br />"Why we should increase the block size" - CEO Brian Armstrong<ref>https://twitter.com/brian_armstrong/status/595453245884997634</ref><br />
|<br />
|- <br />
| [[Dr. Adam Back (individual)|Dr. Adam Back]]<br />
| {{Yes|Yes: "For the record I am not aware of a single person who has said they do not agree with scaling Bitcoin. Changing a constant is not the hard-part. The hard part is validating a plan and the other factors that go into it. It's not a free choice it is a security/scalability tradeoff. No one will thank us if we "scale" bitcoin but break it in hard to recover ways at the same time."}} <ref>https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html</ref><br />
| {{No}}<br />"I strongly urge that we return to the existing collaborative constructive review process that has been used for the last 4 years which is a consensus by design to prevent one rogue person from inserting a backdoor, or lobbying for a favoured change on behalf of a special interest group, or working for bad actor" - Dr. Adam Back<ref>https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html</ref><br />
|<br />
|-<br />
| Kryptoradio<br />
| {{Yes}}<br />"#Kryptoradio dev @zouppen supports 20MB block size in #bitcoin." - Joel Lehtonen<ref>https://twitter.com/koodilehto/status/596675967667568641</ref><br />
|<br />
|- <br />
| OKCoin<br />
| {{Yes|Yes: "OKCoin's tech team believes it's the right decision"}}<ref>https://twitter.com/okcoinbtc/status/598412795240009728</ref><br />
|<br />
|-<br />
| Third Key Solutions<br />
| {{Yes}}<br />"Gavin is right. The time to increase the block size limit is before transaction processing shows congestion problems." - CTO Andreas Antonopoulos<ref>https://twitter.com/aantonop/status/595601619581964289</ref><br />
|<br />
|-<br />
| Xapo<br />
| {{Yes|Yes: "One meg is not enough: Xapo supports increasing the maximum block size"}} - CEO Wences Casares<ref>https://twitter.com/wences/status/595768917907402752</ref><br />
|<br />
|}</div>Lapp0https://en.bitcoin.it/w/index.php?title=Block_size_limit_controversy&diff=57015Block size limit controversy2015-06-17T17:49:43Z<p>Lapp0: removed non-statement</p>
<hr />
<div>== Introduction ==<br />
<br />
Blocks are limited to 1MB in size. Miners can mine blocks upto the 1MB fixed limit. Any block larger than 1MB is invalid.<br />
<br />
The blocksize limit has the dual purpose of discouraging economically frivolous transactions from flooding the blockchain and encouraging transactions fees to incentivize miners.<br />
<br />
The fixed blocksize limit cannot be modified without a hard fork.<br />
<br />
Hard forks require adoption by virtually all of the bitcoin participants.<br />
<br />
== Arguments in favor of increasing the blocksize ==<br />
* More transactions per second<br />
* Increased space for extensibility like SNARKs, Mastercoin, Counterparty, etc.<br />
* Faster confirmation times with lower fees required<br />
<br />
== Arguments in opposition to increasing the blocksize ==<br />
* A hard fork requires waiting for sufficient consensus.<br />
* However an emergency hard fork can achieve consensus for deployment on a short time period if needed.<br />
* Risk of catastrophic consensus failure<ref>https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html</ref><br />
* Orphan rate amplification, more reorgs and double-spends due to slower propagation speeds.<br />
* European/American pools at more of a disadvantage compared to the Chinese pools{{why}}<br />
* No amount of max block size would support all the world's future transactions on the main blockchain (various types of off-chain transactions are the only long-term solution)<br />
* Fast block propagation is either not clearly viable, or (eg, IBLT) creates centralised controls.<br />
<br />
=== Damage to decentalization ===<br />
* Bitcoin is only useful if it is decentralized because centralization requires trust. Bitcoins value proposition is trustlessness.<br />
* The larger the hash-rate a single miner controls, the more centralized Bitcoin becomes and the more trust using Bitcoin requires.<br />
* Running your own full node while mining rather than giving another entity the right to your hash-power decreases the hash-rate of large miners. Those who control hash-power are able to control their own hash power if and only if they run a full node.<br />
* Less individuals who control hash-power will run full nodes if running one becomes more expensive<ref>https://www.weusecoins.com/why-blocksize-limit-keeps-bitcoin-free-decentralized/</ref>.<br />
* Larger blocks leads to more expensive full nodes.<br />
* Therefore, larger blocks lead to less hashers running full nodes, which leads to centralized entities having more power, which makes Bitcoin require more trust, which weakens Bitcoins value proposition.<br />
<br />
== Entities positions ==<br />
Positions below are based on a suggested fixed block size increase to 20MiB. Positions against these larger blocks do not necessarily imply that they are against an increase in general, and may instead support a smaller and/or gradual increase.<br />
{| class="wikitable sortable"<br />
! Entity<br />
! Supports Larger Blocks<br />
! Supports Hard Fork<br />
|-<br />
| Bitcoinpaygate<br />
| {{No|No: "We do NOT support the blocksize increase"}}<ref>http://www.reddit.com/r/Bitcoin/comments/37y8wm/list_of_bitcoin_services_that_supportoppose/crqsnqp</ref><br />
|<br />
|-<br />
| Bitrated<br />
| {{No}}<br />"At this time, I oppose increasing the block size limit as per Gavin's proposal" - Nadav Ivgi (founder)<ref>https://twitter.com/shesek/status/605005384026177537</ref><br />
|<br />
|-<br />
| [[F2Pool]]<br />
| {{No|No: "We do support bigger blocks and sooner rather than later. But we cannot handle 20 MB blocks right now. ... I think we can accept 5MB block at most."}}<ref>http://sourceforge.net/p/bitcoin/mailman/message/34157036/],[http://sourceforge.net/p/bitcoin/mailman/message/34158911/</ref><br />
|<br />
|-<br />
| [[GreenAddress]]<br />
| {{No|No: "In our mind increasing the block size like this is just pushing the problem a little further at potentially unfixable costs."}}<ref>http://www.reddit.com/r/Bitcoin/comments/35anax/list_of_bitcoin_services_that_support_increasing/cr2mq84</ref><br />
|<br />
|-<br />
| [[MPEx]]<br />
| {{No}}<ref>http://log.bitcoin-assets.com//?date=07-01-2015#967332</ref><br />
|<br />
|-<br />
| [[Paymium]]<br />
| {{No|No: "<nowiki>[allow]</nowiki> a sane transaction fee market to emerge, by letting the blocks actually fill-up."}} - CTO David Francois<ref>http://fr.anco.is/2015/gavineries/</ref><br />
| <br />
|-<br />
| Ethereum<br /><br />
| {{Neutral|Neutral: "If <nowiki>[the niche of digital gold]</nowiki> is what Bitcoin users want, then they should keep the limit, and perhaps even decrease it. But if Bitcoin users want to be a payment system, then up it must go."}} - Vitalik Buterin (founder)<ref>http://www.reddit.com/r/ethereum/comments/380q61/i_know_this_may_not_directly_be_ethereum_related/crrofl6</ref><br />
|<br />
|-<br />
| [[Armory]]<br />
| {{Yes}}<br />"This *is* urgent and needs to be handled right now, and I believe Gavin<br />
has the best approach to this." - CEO Alan Reiner<ref>http://sourceforge.net/p/bitcoin/mailman/message/34093337/</ref><br />
|<br />
|-<br />
| BitcoinReminder<br />
| {{Yes|Yes: "BitcoinReminder.com also supports 20MB blocks (or even more?"}}<ref>http://www.reddit.com/r/Bitcoin/comments/37y8wm/list_of_bitcoin_services_that_supportoppose/crs9ytd</ref><br />
|<br />
|-<br />
| BitHours<br />
| {{Yes|Yes: "We support @gavinandresen and his proposal for 20mb blocks"}}<ref>https://twitter.com/bithours/status/605131647747358721</ref><br />
|<br />
|-<br />
| [[BitPay]]<br />
| {{Yes}}<br />"Agreed (but optimistic this will be the last and only time block size needs to increase)" - CEO Stephen Pair<ref>https://twitter.com/spair/status/595341090317799424</ref><br />
| <br />
|-<br />
| Bittiraha.fi<br />
| {{Yes|Yes: "We are supporting increasing #Bitcoin max block size to 20MB."}}<ref>https://twitter.com/Bittirahafi/status/596682373028311040</ref><br />"I'm strongly in favor of the block size cap increase to 20MB." - CEO Henry Brade<ref>https://twitter.com/Technom4ge/status/596334370803326978</ref><br />
| {{Yes}}<br />"And I'm in favor of releasing a version with this change even with opposition." - CEO Henry Brade<ref>https://twitter.com/Technom4ge/status/596334370803326978</ref><br />
|-<br />
| [[Blockchain.info]]<br />
|{{Yes}}<br />"It is time to increase the block size. Agree with @gavinandresen" - CEO Peter Smith<ref>https://twitter.com/OneMorePeter/status/595676380320407553</ref><br />"Scaling #bitcoin is a big deal. Increase the block size." - Nic Cary<ref>https://twitter.com/niccary/status/595707211994763264</ref><br />
|<br />
|-<br />
| Breadwallet<br />
| {{Yes}}<br />"[...] in support of the Gavin's 20Mb block proposal." - CEO Aaron Voisine<ref>http://sourceforge.net/p/bitcoin/mailman/message/34096857/</ref><br />
|<br />
|-<br />
| [[BTC Guild]]<br />
| {{Yes}}<br />"Needs to happen, but needs future expansion built in at a reasonable rate." - Eleuthria<ref>https://www.reddit.com/r/Bitcoin/comments/370rko/21_inc_engineer_everyone_assumes_humans_will_be/crjfnpg?context=3</ref><br />
|<br />
|-<br />
| BX.in.th<br />
| {{Yes|Yes: "<nowiki>http://BX.in.th</nowiki> will support the 20MB block size"}}<ref>https://twitter.com/BitcoinThai/status/605022509101023232</ref><br />
| <br />
|- <br />
| [[Coinbase (business)|CoinBase]]<br />
| {{Yes|Yes: "Coinbase supports increasing the maximum block size"}}<ref>https://twitter.com/coinbase/status/595741967759335426</ref><br />"Why we should increase the block size" - CEO Brian Armstrong<ref>https://twitter.com/brian_armstrong/status/595453245884997634</ref><br />
|<br />
|- <br />
| [[Dr. Adam Back (individual)|Dr. Adam Back]]<br />
| {{Yes|Yes: "For the record I am not aware of a single person who has said they do not agree with scaling Bitcoin. Changing a constant is not the hard-part. The hard part is validating a plan and the other factors that go into it. It's not a free choice it is a security/scalability tradeoff. No one will thank us if we "scale" bitcoin but break it in hard to recover ways at the same time."}} <ref>https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html</ref><br />
| {{No}}<br />"I strongly urge that we return to the existing collaborative constructive review process that has been used for the last 4 years which is a consensus by design to prevent one rogue person from inserting a backdoor, or lobbying for a favoured change on behalf of a special interest group, or working for bad actor" - Dr. Adam Back<ref>https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html</ref><br />
|<br />
|-<br />
| Kryptoradio<br />
| {{Yes}}<br />"#Kryptoradio dev @zouppen supports 20MB block size in #bitcoin." - Joel Lehtonen<ref>https://twitter.com/koodilehto/status/596675967667568641</ref><br />
|<br />
|- <br />
| OKCoin<br />
| {{Yes|Yes: "OKCoin's tech team believes it's the right decision"}}<ref>https://twitter.com/okcoinbtc/status/598412795240009728</ref><br />
|<br />
|-<br />
| Third Key Solutions<br />
| {{Yes}}<br />"Gavin is right. The time to increase the block size limit is before transaction processing shows congestion problems." - CTO Andreas Antonopoulos<ref>https://twitter.com/aantonop/status/595601619581964289</ref><br />
|<br />
|-<br />
| Xapo<br />
| {{Yes|Yes: "One meg is not enough: Xapo supports increasing the maximum block size"}} - CEO Wences Casares<ref>https://twitter.com/wences/status/595768917907402752</ref><br />
|<br />
|}</div>Lapp0https://en.bitcoin.it/w/index.php?title=Scalability&diff=56988Scalability2015-06-15T04:17:15Z<p>Lapp0: rewording, added benefit</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 12000 Intel Core i7-2670QM 2.2Ghz processors. 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. Otherwise, our result is a few centralized parties that control the blockchain and are able to reverse or censor transactions.<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><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>Lapp0https://en.bitcoin.it/w/index.php?title=Scalability&diff=56987Scalability2015-06-15T04:14:04Z<p>Lapp0: fix broken link</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 12000 Intel Core i7-2670QM 2.2Ghz processors. 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. Otherwise, our result is a few centralized parties that control the blockchain and are able to reverse or censor transactions.<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). Similar to the blockchain, Lighting doesn't have a counterparty risk, no one can steal your bitcoin. Lightning, however, doesn't require everyone to process every copy of every trustless transaction in order to be secure. In addition, Lightning has instant confirmations.<ref>[http://lightning.network/lightning-network.pdf Lighting Network]</ref><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>Lapp0https://en.bitcoin.it/w/index.php?title=Scalability&diff=56986Scalability2015-06-15T04:13:13Z<p>Lapp0: Added other scalability options</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>[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 12000 Intel Core i7-2670QM 2.2Ghz processors. 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. Otherwise, our result is a few centralized parties that control the blockchain and are able to reverse or censor transactions.<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). Similar to the blockchain, Lighting doesn't have a counterparty risk, no one can steal your bitcoin. Lightning, however, doesn't require everyone to process every copy of every trustless transaction in order to be secure. In addition, Lightning has instant confirmations.<ref>[http://lightning.network/lightning-network.pdf Lighting Network]</ref><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>Lapp0https://en.bitcoin.it/w/index.php?title=Block_size_limit_controversy&diff=56985Block size limit controversy2015-06-15T03:26:36Z<p>Lapp0: Satoshi quotes probably belong in the Entities positions section if they belong here at all</p>
<hr />
<div>== Introduction ==<br />
<br />
Blocks are limited to 1MB in size. Miners can mine blocks upto the 1MB fixed limit. Any block larger than 1MB is invalid.<br />
<br />
The blocksize limit has the dual purpose of discouraging economically frivolous transactions from flooding the blockchain and encouraging transactions fees to incentivize miners.<br />
<br />
The fixed blocksize limit cannot be modified without a hard fork.<br />
<br />
Hard forks require adoption by virtually all of the bitcoin participants.<br />
<br />
== Arguments in favor of increasing the blocksize ==<br />
* Bigger blocks (more transactions per second)<br />
<br />
== Arguments in opposition to increasing the blocksize ==<br />
* A hard fork requires waiting for sufficient consensus.<br />
* However an emergency hard fork can achieve consensus for deployment on a short time period if needed.<br />
* Risk of catastrophic consensus failure{{clarification needed}}<br />
* Orphan rate amplification, more reorgs and double-spends due to slower propagation speeds.<br />
* European/American pools at more of a disadvantage compared to the Chinese pools{{why}}<br />
* No amount of max block size would support all the world's future transactions on the main blockchain (various types of off-chain transactions are the only long-term solution)<br />
* Fast block propagation is either not clearly viable, or (eg, IBLT) creates centralised controls.<br />
<br />
=== Damage to decentalization ===<br />
* Bitcoin is only useful if it is decentralized because centralization requires trust. Bitcoins value proposition is trustlessness.<br />
* The larger the hash-rate a single miner controls, the more centralized Bitcoin becomes and the more trust using Bitcoin requires.<br />
* Running your own full node while mining rather than giving another entity the right to your hash-power decreases the hash-rate of large miners. Those who control hash-power are able to control their own hash power if and only if they run a full node.<br />
* Less individuals who control hash-power will run full nodes if running one becomes more expensive.<br />
* Larger blocks leads to more expensive full nodes.<br />
* Therefore, larger blocks lead to less hashers running full nodes, which leads to centralized entities having more power, which makes Bitcoin require more trust, which weakens Bitcoins value proposition.<br />
<br />
== Entities positions ==<br />
Positions below are based on a suggested fixed block size increase to 20MiB. Positions against these larger blocks do not necessarily imply that they are against an increase in general, and may instead support a smaller and/or gradual increase.<br />
{| class="wikitable sortable"<br />
! Entity<br />
! Supports Larger Blocks<br />
! Supports Hard Fork<br />
|-<br />
| Bitcoinpaygate<br />
| {{No|No: "We do NOT support the blocksize increase"}}<ref>http://www.reddit.com/r/Bitcoin/comments/37y8wm/list_of_bitcoin_services_that_supportoppose/crqsnqp</ref><br />
|<br />
|-<br />
| Bitrated<br />
| {{No}}<br />"At this time, I oppose increasing the block size limit as per Gavin's proposal" - Nadav Ivgi (founder)<ref>https://twitter.com/shesek/status/605005384026177537</ref><br />
|<br />
|-<br />
| [[F2Pool]]<br />
| {{No|No: "We do support bigger blocks and sooner rather than later. But we cannot handle 20 MB blocks right now. ... I think we can accept 5MB block at most."}}<ref>http://sourceforge.net/p/bitcoin/mailman/message/34157036/],[http://sourceforge.net/p/bitcoin/mailman/message/34158911/</ref><br />
|<br />
|-<br />
| [[GreenAddress]]<br />
| {{No|No: "In our mind increasing the block size like this is just pushing the problem a little further at potentially unfixable costs."}}<ref>http://www.reddit.com/r/Bitcoin/comments/35anax/list_of_bitcoin_services_that_support_increasing/cr2mq84</ref><br />
|<br />
|-<br />
| [[MPEx]]<br />
| {{No}}<ref>http://log.bitcoin-assets.com//?date=07-01-2015#967332</ref><br />
|<br />
|-<br />
| [[Paymium]]<br />
| {{No|No: "<nowiki>[allow]</nowiki> a sane transaction fee market to emerge, by letting the blocks actually fill-up."}} - CTO David Francois<ref>http://fr.anco.is/2015/gavineries/</ref><br />
| <br />
|-<br />
| Ethereum<br /><br />
| {{Neutral|Neutral: "If <nowiki>[the niche of digital gold]</nowiki> is what Bitcoin users want, then they should keep the limit, and perhaps even decrease it. But if Bitcoin users want to be a payment system, then up it must go."}} - Vitalik Buterin (founder)<ref>http://www.reddit.com/r/ethereum/comments/380q61/i_know_this_may_not_directly_be_ethereum_related/crrofl6</ref><br />
|<br />
|-<br />
| [[Armory]]<br />
| {{Yes}}<br />"This *is* urgent and needs to be handled right now, and I believe Gavin<br />
has the best approach to this." - CEO Alan Reiner<ref>http://sourceforge.net/p/bitcoin/mailman/message/34093337/</ref><br />
|<br />
|-<br />
| BitcoinReminder<br />
| {{Yes|Yes: "BitcoinReminder.com also supports 20MB blocks (or even more?"}}<ref>http://www.reddit.com/r/Bitcoin/comments/37y8wm/list_of_bitcoin_services_that_supportoppose/crs9ytd</ref><br />
|<br />
|-<br />
| BitHours<br />
| {{Yes|Yes: "We support @gavinandresen and his proposal for 20mb blocks"}}<ref>https://twitter.com/bithours/status/605131647747358721</ref><br />
|<br />
|-<br />
| [[BitPay]]<br />
| {{Yes}}<br />"Agreed (but optimistic this will be the last and only time block size needs to increase)" - CEO Stephen Pair<ref>https://twitter.com/spair/status/595341090317799424</ref><br />
| <br />
|-<br />
| Bittiraha.fi<br />
| {{Yes|Yes: "We are supporting increasing #Bitcoin max block size to 20MB."}}<ref>https://twitter.com/Bittirahafi/status/596682373028311040</ref><br />"I'm strongly in favor of the block size cap increase to 20MB." - CEO Henry Brade<ref>https://twitter.com/Technom4ge/status/596334370803326978</ref><br />
| {{Yes}}<br />"And I'm in favor of releasing a version with this change even with opposition." - CEO Henry Brade<ref>https://twitter.com/Technom4ge/status/596334370803326978</ref><br />
|-<br />
| [[Blockchain.info]]<br />
|{{Yes}}<br />"It is time to increase the block size. Agree with @gavinandresen" - CEO Peter Smith<ref>https://twitter.com/OneMorePeter/status/595676380320407553</ref><br />"Scaling #bitcoin is a big deal. Increase the block size." - Nic Cary<ref>https://twitter.com/niccary/status/595707211994763264</ref><br />
|<br />
|-<br />
| Breadwallet<br />
| {{Yes}}<br />"[...] in support of the Gavin's 20Mb block proposal." - CEO Aaron Voisine<ref>http://sourceforge.net/p/bitcoin/mailman/message/34096857/</ref><br />
|<br />
|-<br />
| [[BTC Guild]]<br />
| {{Yes}}<br />"Needs to happen, but needs future expansion built in at a reasonable rate." - Eleuthria<ref>https://www.reddit.com/r/Bitcoin/comments/370rko/21_inc_engineer_everyone_assumes_humans_will_be/crjfnpg?context=3</ref><br />
|<br />
|-<br />
| BX.in.th<br />
| {{Yes|Yes: "<nowiki>http://BX.in.th</nowiki> will support the 20MB block size"}}<ref>https://twitter.com/BitcoinThai/status/605022509101023232</ref><br />
| <br />
|- <br />
| [[Coinbase (business)|CoinBase]]<br />
| {{Yes|Yes: "Coinbase supports increasing the maximum block size"}}<ref>https://twitter.com/coinbase/status/595741967759335426</ref><br />"Why we should increase the block size" - CEO Brian Armstrong<ref>https://twitter.com/brian_armstrong/status/595453245884997634</ref><br />
|<br />
|-<br />
| Kryptoradio<br />
| {{Yes}}<br />"#Kryptoradio dev @zouppen supports 20MB block size in #bitcoin." - Joel Lehtonen<ref>https://twitter.com/koodilehto/status/596675967667568641</ref><br />
|<br />
|- <br />
| OKCoin<br />
| {{Yes|Yes: "OKCoin's tech team believes it's the right decision"}}<ref>https://twitter.com/okcoinbtc/status/598412795240009728</ref><br />
|<br />
|-<br />
| Third Key Solutions<br />
| {{Yes}}<br />"Gavin is right. The time to increase the block size limit is before transaction processing shows congestion problems." - CTO Andreas Antonopoulos<ref>https://twitter.com/aantonop/status/595601619581964289</ref><br />
|<br />
|-<br />
| Xapo<br />
| {{Yes|Yes: "One meg is not enough: Xapo supports increasing the maximum block size"}} - CEO Wences Casares<ref>https://twitter.com/wences/status/595768917907402752</ref><br />
|<br />
|}</div>Lapp0https://en.bitcoin.it/w/index.php?title=Block_size_limit_controversy&diff=56948Block size limit controversy2015-06-13T10:10:01Z<p>Lapp0: Block Sizes being full aren't a reason for a hardfork</p>
<hr />
<div>== Introduction ==<br />
<br />
Blocks are limited to 1MB in size. Miners can mine blocks upto the 1MB fixed limit. Any block larger than 1MB is invalid.<br />
<br />
Blocksize limits were put in place for the dual purposes of discouraging economically frivolous transactions from flooding the blockchain and encouraging transactions fees to incentivize miners.<br />
<br />
{{Quote|Once a predetermined number of coins have entered circulation, the incentive can transition entirely to transaction fees and be completely inflation free.|Satoshi Nakamoto <ref>https://bitcoin.org/bitcoin.pdf</ref>}}<br />
<br />
The fixed blocksize limit cannot be modified without a hard fork.<br />
<br />
Hard forks require adoption by virtually all of the bitcoin participants.<br />
<br />
== Arguments in favor of increasing the blocksize ==<br />
* Bigger blocks (more transactions per second)<br />
<br />
== Arguments in opposition to increasing the blocksize ==<br />
* A hard fork requires waiting for sufficient consensus.<br />
* However an emergency hard fork can achieve consensus for deployment on a short time period if needed.<br />
* Risk of catastrophic consensus failure{{clarification needed}}<br />
* Orphan rate amplification, more reorgs and double-spends due to slower propagation speeds.<br />
* European/American pools at more of a disadvantage compared to the Chinese pools{{why}}<br />
* No amount of max block size would support all the world's future transactions on the main blockchain (various types of off-chain transactions are the only long-term solution)<br />
* Fast block propagation is either not clearly viable, or (eg, IBLT) creates centralised controls.<br />
<br />
=== Damage to decentalization ===<br />
* Bitcoin is only useful if it is decentralized because centralization requires trust. Bitcoins value proposition is trustlessness.<br />
* The larger the hash-rate a single miner controls, the more centralized Bitcoin becomes and the more trust using Bitcoin requires.<br />
* Running your own full node while mining rather than giving another entity the right to your hash-power decreases the hash-rate of large miners. Those who control hash-power are able to control their own hash power if and only if they run a full node.<br />
* Less individuals who control hash-power will run full nodes if running one becomes more expensive.<br />
* Larger blocks leads to more expensive full nodes.<br />
* Therefore, larger blocks lead to less hashers running full nodes, which leads to centralized entities having more power, which makes Bitcoin require more trust, which weakens Bitcoins value proposition.<br />
<br />
== Entities positions ==<br />
Positions below are based on a suggested fixed block size increase to 20MiB. Positions against these larger blocks do not necessarily imply that they are against an increase in general, and may instead support a smaller and/or gradual increase.<br />
{| class="wikitable sortable"<br />
! Entity<br />
! Supports Larger Blocks<br />
! Supports Hard Fork<br />
|-<br />
| Bitcoinpaygate<br />
| {{No|No: "We do NOT support the blocksize increase"}}<ref>http://www.reddit.com/r/Bitcoin/comments/37y8wm/list_of_bitcoin_services_that_supportoppose/crqsnqp</ref><br />
|<br />
|-<br />
| Bitrated<br />
| {{No}}<br />"At this time, I oppose increasing the block size limit as per Gavin's proposal" - Nadav Ivgi (founder)<ref>https://twitter.com/shesek/status/605005384026177537</ref><br />
|<br />
|-<br />
| [[F2Pool]]<br />
| {{No|No: "We do support bigger blocks and sooner rather than later. But we cannot handle 20 MB blocks right now. ... I think we can accept 5MB block at most."}}<ref>http://sourceforge.net/p/bitcoin/mailman/message/34157036/],[http://sourceforge.net/p/bitcoin/mailman/message/34158911/</ref><br />
|<br />
|-<br />
| [[GreenAddress]]<br />
| {{No|No: "In our mind increasing the block size like this is just pushing the problem a little further at potentially unfixable costs."}}<ref>http://www.reddit.com/r/Bitcoin/comments/35anax/list_of_bitcoin_services_that_support_increasing/cr2mq84</ref><br />
|<br />
|-<br />
| [[MPEx]]<br />
| {{No}}<ref>http://log.bitcoin-assets.com//?date=07-01-2015#967332</ref><br />
|<br />
|-<br />
| [[Paymium]]<br />
| {{No|No: "<nowiki>[allow]</nowiki> a sane transaction fee market to emerge, by letting the blocks actually fill-up."}} - CTO David Francois<ref>http://fr.anco.is/2015/gavineries/</ref><br />
| <br />
|-<br />
| Ethereum<br /><br />
| {{Neutral|Neutral: "If <nowiki>[the niche of digital gold]</nowiki> is what Bitcoin users want, then they should keep the limit, and perhaps even decrease it. But if Bitcoin users want to be a payment system, then up it must go."}} - Vitalik Buterin (founder)<ref>http://www.reddit.com/r/ethereum/comments/380q61/i_know_this_may_not_directly_be_ethereum_related/crrofl6</ref><br />
|<br />
|-<br />
| [[Armory]]<br />
| {{Yes}}<br />"This *is* urgent and needs to be handled right now, and I believe Gavin<br />
has the best approach to this." - CEO Alan Reiner<ref>http://sourceforge.net/p/bitcoin/mailman/message/34093337/</ref><br />
|<br />
|-<br />
| BitcoinReminder<br />
| {{Yes|Yes: "BitcoinReminder.com also supports 20MB blocks (or even more?"}}<ref>http://www.reddit.com/r/Bitcoin/comments/37y8wm/list_of_bitcoin_services_that_supportoppose/crs9ytd</ref><br />
|<br />
|-<br />
| BitHours<br />
| {{Yes|Yes: "We support @gavinandresen and his proposal for 20mb blocks"}}<ref>https://twitter.com/bithours/status/605131647747358721</ref><br />
|<br />
|-<br />
| [[BitPay]]<br />
| {{Yes}}<br />"Agreed (but optimistic this will be the last and only time block size needs to increase)" - CEO Stephen Pair<ref>https://twitter.com/spair/status/595341090317799424</ref><br />
| <br />
|-<br />
| Bittiraha.fi<br />
| {{Yes|Yes: "We are supporting increasing #Bitcoin max block size to 20MB."}}<ref>https://twitter.com/Bittirahafi/status/596682373028311040</ref><br />"I'm strongly in favor of the block size cap increase to 20MB." - CEO Henry Brade<ref>https://twitter.com/Technom4ge/status/596334370803326978</ref><br />
| {{Yes}}<br />"And I'm in favor of releasing a version with this change even with opposition." - CEO Henry Brade<ref>https://twitter.com/Technom4ge/status/596334370803326978</ref><br />
|-<br />
| [[Blockchain.info]]<br />
|{{Yes}}<br />"It is time to increase the block size. Agree with @gavinandresen" - CEO Peter Smith<ref>https://twitter.com/OneMorePeter/status/595676380320407553</ref><br />"Scaling #bitcoin is a big deal. Increase the block size." - Nic Cary<ref>https://twitter.com/niccary/status/595707211994763264</ref><br />
|<br />
|-<br />
| Breadwallet<br />
| {{Yes}}<br />"[...] in support of the Gavin's 20Mb block proposal." - CEO Aaron Voisine<ref>http://sourceforge.net/p/bitcoin/mailman/message/34096857/</ref><br />
|<br />
|-<br />
| [[BTC Guild]]<br />
| {{Yes}}<br />"Needs to happen, but needs future expansion built in at a reasonable rate." - Eleuthria<ref>https://www.reddit.com/r/Bitcoin/comments/370rko/21_inc_engineer_everyone_assumes_humans_will_be/crjfnpg?context=3</ref><br />
|<br />
|-<br />
| BX.in.th<br />
| {{Yes|Yes: "<nowiki>http://BX.in.th</nowiki> will support the 20MB block size"}}<ref>https://twitter.com/BitcoinThai/status/605022509101023232</ref><br />
| <br />
|- <br />
| [[Coinbase (business)|CoinBase]]<br />
| {{Yes|Yes: "Coinbase supports increasing the maximum block size"}}<ref>https://twitter.com/coinbase/status/595741967759335426</ref><br />"Why we should increase the block size" - CEO Brian Armstrong<ref>https://twitter.com/brian_armstrong/status/595453245884997634</ref><br />
|<br />
|-<br />
| Kryptoradio<br />
| {{Yes}}<br />"#Kryptoradio dev @zouppen supports 20MB block size in #bitcoin." - Joel Lehtonen<ref>https://twitter.com/koodilehto/status/596675967667568641</ref><br />
|<br />
|- <br />
| OKCoin<br />
| {{Yes|Yes: "OKCoin's tech team believes it's the right decision"}}<ref>https://twitter.com/okcoinbtc/status/598412795240009728</ref><br />
|<br />
|-<br />
| Third Key Solutions<br />
| {{Yes}}<br />"Gavin is right. The time to increase the block size limit is before transaction processing shows congestion problems." - CTO Andreas Antonopoulos<ref>https://twitter.com/aantonop/status/595601619581964289</ref><br />
|<br />
|-<br />
| Xapo<br />
| {{Yes|Yes: "One meg is not enough: Xapo supports increasing the maximum block size"}} - CEO Wences Casares<ref>https://twitter.com/wences/status/595768917907402752</ref><br />
|<br />
|}</div>Lapp0https://en.bitcoin.it/w/index.php?title=Block_size_limit_controversy&diff=56789Block size limit controversy2015-06-01T15:35:24Z<p>Lapp0: /* Argument in opposition of increasing the blocksize */</p>
<hr />
<div>== Argument in favor of increasing the blocksize ==<br />
* Bigger blocks (more transactions per second)<br />
* Sidechains and Lightning require waiting for development.<br />
<br />
== Argument in opposition of increasing the blocksize ==<br />
* A hard fork requires waiting for sufficient consensus.<br />
* Orphan rate magnification, more reorgs and double-spends due to slower propagation speeds.<br />
* European/American pools at more of a disadvantage compared to the Chinese pools{{why}}<br />
* No amount of max block size would support all the world's future transactions on the main blockchain (various types of off-chain transactions are the only long-term solution)<br />
* Risk of catastrophic consensus failure{{clarification needed}}<br />
<br />
=== Damage to decentalization ===<br />
* Bitcoin is only useful if it is decentralized because centralization requires trust. Bitcoins value proposition is trustlessness.<br />
<br />
* The larger the hash-rate a single miner controls, the more centralized Bitcoin becomes and the more trust using Bitcoin requires.<br />
<br />
* Running your own full node while mining rather than giving another entity the right to your hash-power decreases the hash-rate of large miners. Those who control hash-power are able to control their own hash power if and only if they run a full node.<br />
<br />
* Less individuals who control hash-power will run full nodes if running one becomes more expensive.<br />
<br />
* Larger blocks leads to more expensive full nodes.<br />
<br />
* Therefore, larger blocks lead to less hashers running full nodes, which leads to centralized entities having more power, which makes Bitcoin require more trust, which weakens Bitcoins value proposition.<br />
<br />
{| class="wikitable sortable"<br />
! Entity<br />
! Supports Larger Blocks<br />
! Supports Hard Fork<br />
|- <br />
| CoinBase<br />
|{{Yes}}<br />
|<br />
|}</div>Lapp0https://en.bitcoin.it/w/index.php?title=Block_size_limit_controversy&diff=56774Block size limit controversy2015-06-01T11:09:03Z<p>Lapp0: </p>
<hr />
<div>== Argument in favor of increasing the blocksize ==<br />
* Bigger blocks (more transactions per second)<br />
* Sidechains and Lightning require waiting for development.<br />
<br />
== Argument in opposition of increasing the blocksize ==<br />
* A hard fork requires waiting for sufficient consensus.<br />
* Orphan rate magnification, more reorgs and double-spends<br />
* European/American pools at more of a disadvantage compared to the Chinese pools<br />
* No amount of max block size would support all the world's future transactions on the main blockchain (various types of off-chain transactions are the only long-term solution)<br />
* Risk of catastrophic consensus failure<br />
<br />
=== Damage to decentalization ===<br />
* Bitcoin is only useful if it is decentralized because centralization requires trust. Bitcoins value proposition is trustlessness.<br />
<br />
* The larger the hash-rate a single miner controls, the more centralized Bitcoin becomes and the more trust using Bitcoin requires.<br />
<br />
* Running your own full node while mining rather than giving another entity the right to your hash-power decreases the hash-rate of large miners. Those who control hash-power are able to control their own hash power if and only if they run a full node.<br />
<br />
* Less individuals who control hash-power will run full nodes if running one becomes more expensive.<br />
<br />
* Larger blocks leads to more expensive full nodes.<br />
<br />
* Therefore, larger blocks lead to less hashers running full nodes, which leads to centralized entities having more power, which makes Bitcoin require more trust, which weakens Bitcoins value proposition.<br />
<br />
{| class="wikitable sortable"<br />
! Entity<br />
! Supports Larger Blocks<br />
! Supports Hard Fork<br />
|- <br />
| CoinBase<br />
|{{Yes}}<br />
|<br />
|}</div>Lapp0https://en.bitcoin.it/w/index.php?title=Block_size_limit_controversy&diff=56750Block size limit controversy2015-06-01T01:19:24Z<p>Lapp0: </p>
<hr />
<div>== Argument in favor of increasing the blocksize ==<br />
* Bigger blocks (more transactions per second)<br />
== Argument in opposition of increasing the blocksize ==<br />
* Risk of catastrophic consensus failure<br />
=== Damage to decentalization ===<br />
* Bitcoin is only useful if it is decentralized because centralization requires trust. Bitcoins value proposition is trustlessness.<br />
<br />
* The larger the hash-rate a single miner controls, the more centralized Bitcoin becomes and the more trust using Bitcoin requires.<br />
<br />
* Running your own full node while mining rather than giving another entity the right to your hash-power decreases the hash-rate of large miners. Those who control hash-power are able to control their own hash power if and only if they run a full node.<br />
<br />
* Less individuals who control hash-power will run full nodes if running one becomes more expensive.<br />
<br />
* Larger blocks leads to more expensive full nodes.<br />
<br />
* Therefore, larger blocks lead to less hashers running full nodes, which leads to centralized entities having more power, which makes Bitcoin require more trust, which weakens Bitcoins value proposition.<br />
<br />
{| class="wikitable sortable"<br />
! Entity<br />
! Supports Larger Blocks<br />
! Supports Hard Fork<br />
|- <br />
| CoinBase<br />
|{{Yes}}<br />
|<br />
|}</div>Lapp0https://en.bitcoin.it/w/index.php?title=Address_reuse&diff=55476Address reuse2015-03-16T10:15:33Z<p>Lapp0: high fees when displaying address balances</p>
<hr />
<div>Address reuse is the practice of sending multiple transactions to the same address.<br />
This works by "accident", not by design.<br />
It is considered a bad practice, and not something that should be done.<br />
<br />
== Problems ==<br />
=== Privacy ===<br />
Address reuse harms the privacy of not only yourself, but also others - including many not related to the transaction.<br />
In some cases, these risks are serious enough that they are likely in violation of reasonable consumer protection laws.<br />
<br />
When addresses are re-used, they allow others to much more easily and reliably determine that the address being reused is yours. Every time the re-used address's private key signs a fresh transaction, whoever receives it can use the histories of that address to discover information about you, and everyone who is interested in discovering the identity of the address's owner has one more target they can try to contact to discover who you are.<br />
<br />
The relationship graph in a re-used address is powerfully-linked in that '''all''' of the inputs to that address are necessarily joined (via the spending authority of your private key) to all of its outputs.<br />
<br />
There has been significant research into the area of what researchers are calling 'identity collapse', which is what happens when more than one Bitcoin address is strongly-linked via the Bitcoin transaction graph to another. Re-using addresses makes their job trivial. There are publically-known databases that exist, right now, that have not only collapsed millions of Bitcoin addresses, but used publically-available information to '''link''' those collapsed identities to individuals, and these databases are being actively maintained.<br />
<br />
While you may be okay with some random European researcher bound by his ethics board to conceal your identity from the public at-large, it is very possible that people who accept money from you may not be aware of your decision: thus, via your privacy-decreasing action, people further on the address signing chain could thus be putting '''you''' at risk if they spend their Bitcoin on something that catches the attention of law enforcement.<br />
<br />
Additionally, in the event that you knowingly make this choice (which you are doing, now that you've read this,) the transaction histories that you are responsible for linking in the event you are a retailer of some sort could put the privacy of your customers at risk because now your well-known singular address(es) which can be strongly linked to your corporate identity can be assumed to be economic activity interacting with your corporate identity.<br />
<br />
See also: [http://www.bitcoinnotbombs.com/innovations-that-enhance-bitcoin-anonymity/ Innovations that Enhance Bitcoin Anonymity]<br />
<br />
=== Security ===<br />
Bitcoin does not, at a low level, have any concept of addresses, only individual coins.<br />
Address reuse, at this layer, requires producing multiple digital signatures when you spend bitcoins.<br />
Multiple situations have been found where more than one digital signature can be used to calculate the private key needed to spend bitcoins.<br />
Even if you spend all the bitcoins claimed by this private key at once, it is still possible to double-spend them in theft before they confirm.<br />
While the known situations for finding the private key from signatures have been fixed, it is not prudent to assume there aren't more such situations yet unknown.<br />
<br />
In the case of spending all the TXOs in a single transaction, there is an additional risk if someone is actively monitoring the network for vulnerable transactions:<br />
upon receiving such a transaction, they can split up their double spends such that there is only one ECDSA verification per transaction (making a single transaction for each TXO);<br />
this will cause the attacker's transactions to relay across the rest of the nodes ''faster'' than the legitimate one, increasing success of a double spend.<br />
<br />
==== Known attacks ====<br />
<br />
* Same K in multiple signatures, see [http://www.nilsschneider.net/2013/01/28/recovering-bitcoin-private-keys.html Recovering Bitcoin private keys using weak signatures from the blockchain].<br />
* [https://eprint.iacr.org/2014/140.pdf Timing sidechannel]<br />
<br />
=== Accidental loss ===<br />
In Bitcoin abstraction, an address is an invoice for a specific payment.<br />
Once that payment is made, the receiving party has no reason to retain the data for the address (technical details simplified) and may discard it.<br />
Even if someone does not choose to discard that data, it may have since been lost in an accident or compromised.<br />
In any of these situations, any future payments to the same address would go in to a "black hole", and be forever lost through no fault of the recipient.<br />
<br />
=== Confusion ===<br />
Users who see addresses reused may incorrectly be led to believe they function similarly to wallets or bank accounts.<br />
Often this is manifested in people talking about nonsense like "[[Address#Address_balances|address balance]]", "wallet address", "[[From_address|from address]]", and similar [[Address#Misconceptions|misconceptions]] that don't actually exist in Bitcoin.<br />
<br />
=== High Fees ===<br />
A single invoice payment using P2PKH can be redeemed and spent with a predictable fee because the transaction should have a predictable size. Software that determines payment and available funds based on "address balance" can cause loss through high fees. If you are paid to an address in many small increments, you will pay a much higher transaction fee when redeeming those payments. It is much more useful for a client to display transaction outputs spendable than address balances for this reason.<br />
<br />
== Notable offenders ==<br />
Some notable Bitcoin software and services encourage or require address reuse:<br />
* Many bitcoin mining pools (especially [[Eligius]])<br />
* Electrum displays addresses in a way that encourages confusion and address reuse and misuse.</div>Lapp0https://en.bitcoin.it/w/index.php?title=Majority_attack&diff=55402Majority attack2015-03-15T01:13:58Z<p>Lapp0: </p>
<hr />
<div>A '''majority attack''' (usually labeled '''51% attack''' or '''>50% attack''') is an attack on the network. This attack has a chance to work even if the merchant waits for some confirmations, but requires extremely high relative hashrate.<br />
<br />
The attacker submits to the merchant/network a transaction which pays the merchant, while privately mining a blockchain fork in which a [[double-spending|double-spending transaction]] is included instead. After waiting for ''n'' confirmations, the merchant sends the product. If the attacker happened to find more than ''n'' blocks at this point, he releases his fork and regains his coins; otherwise, he can try to continue extending his fork with the hope of being able to catch up with the network. If he never manages to do this, the attack fails and the payment to the merchant will go through. The work done mining will also go to waste, as any new bitcoins would be overwritten by the longest chain.<br />
<br />
The probability of success is a function of the attacker's hashrate (as a proportion of the total network hashrate) and the number of confirmations the merchant waits for. For example, if the attacker controls 10% of the network hashrate but the merchant waits for 6 confirmations, the success probability is on the order of 0.1%. If the attacker controls more than half of the network hashrate, this has a probability of 100% to succeed. Since the attacker can generate blocks faster than the rest of the network, he can simply persevere with his private fork until it becomes longer than the branch built by the honest network, from whatever disadvantage.<br />
<br />
No amount of confirmations can prevent this attack; however, waiting for confirmations does increase the aggregate resource cost of performing the attack, which could make it unprofitable or delay it long enough for the circumstances to change or slower-acting synchronization methods to kick in. A majority attack was more feasible in the past when most transactions were worth significantly more than the block reward and when the network hashrate was much lower and prone to reorganization with the advent of new mining technologies.<br />
<br />
A majority attack has never been executed on the Bitcoin network.<br />
<br />
==See Also==<br />
<br />
[https://people.xiph.org/~greg/attack_success.html Attack success probability calculator]<br />
<br />
[[Category:Technical]]</div>Lapp0https://en.bitcoin.it/w/index.php?title=Mastering_Bitcoin&diff=55276Mastering Bitcoin2015-03-12T18:20:17Z<p>Lapp0: </p>
<hr />
<div>'''''Mastering Bitcoin''''' by Andreas M. Antonopoulos is [http://chimera.labs.oreilly.com/books/1234000001802/index.html a freely-available book] on Bitcoin by O'Reilly publishers, published in 2015. Mastering Bitcoin has been criticized for plagiarizing this wiki<ref>https://github.com/aantonop/bitcoinbook/blob/develop/appdx-scriptops.asciidoc</ref><ref>https://en.bitcoin.it/wiki/Script</ref> and promoting bad practices that may lead to theft and deanonymization.<br />
{{stub}}<br />
[[Category:Educational]]<br />
{{italic}}<br />
==See Also==<br />
[https://bitcoin.org/en/developer-guide Bitcoin.org Developer Guide]<br />
*[http://chimera.labs.oreilly.com/books/1234000001802/index.html DRM-free book from O'Reilly]<br />
*[https://github.com/aantonop/bitcoinbook GitHub page]<br />
<br />
==References==<br />
<br />
<references/></div>Lapp0https://en.bitcoin.it/w/index.php?title=Thin_Client_Security&diff=54804Thin Client Security2015-03-02T20:37:42Z<p>Lapp0: Removed link to ambiguous comment</p>
<hr />
<div>Recently there have been a number of proposals for bitcoin clients which do not store a complete copy of every block in the entire block chain. This page will refer to all such clients as "thin clients". This page is meant to be a place to try to make sense of the security and trust implications of the various schemes.<br />
<br />
== Full Node vs. SPV ==<br />
<br />
It is important to distinguish between block height verification and block depth verification.<br />
<br />
A full node client verifies that all preceding blocks are valid in order to guarantee that a transaction is valid. Currently only the Satoshi client, libbitcoin, and btcd do full node verification. Full nodes are the fundamental anchor of trustless security in the Bitcoin system.<br />
<br />
A client verifies the depth D of a block by checking that there are D blocks '''after''' it (also called "confirmations"), all of which are well-formed. SPV clients don't verify the preceding blocks, they use the number of confirmations (whether they are valid or not) as a measure of the likelihood of a [[Chain_Reorganization|block chain reorganization]] producing a new longer fork which excludes the transaction.<br />
<br />
== Full Node Clients ==<br />
<br />
The "thick" bitcoin client downloads a copy of the entire chain, including all transactions (not just headers). It will be used as the reference point for security comparisons below.<br />
<br />
A full-node client uses the [[Protocol_rules#Blocks well-formed|difficultywise-longest]] valid block chain it can find. A transaction's ''depth'' (the number of blocks or confirmations ''after'' it) is used to determine the likelihood of the transaction being double-spent due to the emergence of a longer fork.<br />
<br />
==== [[bitcoind|bitcoin-qt]] ====<br />
<br />
==== [https://github.com/conformal/btcd btcd] ====<br />
<br />
=== Block Retention ===<br />
<br />
Once a full-chain client has downloaded the entire chain, it typically retains it (as the Satoshi client did/does).<br />
<br />
Satoshi's original paper mentions the possibility of pruning individual transactions, which allows for full nodes which verify the entire transaction history but do not retain it. Because users are required to download and verify the block chain from some other node initially, this change isn't costless.<br />
<br />
<br />
== Simplified Payment Verification (SPV) Clients ==<br />
<br />
This client downloads a complete copy of the headers for all blocks in the entire block chain. This means that the download and storage requirements scale linearly with the amount of time since Bitcoin was invented.<br />
<br />
This scheme is described in section 8 of the [http://bitcoin.org/bitcoin.pdf original bitcoin whitepaper].<br />
<br />
==== Block Depth Check ====<br />
<br />
As Satoshi writes, "[the thin client] can't check the transaction for himself, but by linking it to a place in the chain, he can see that a network node has accepted it, and blocks added after it further confirm the network has accepted it." If we take "X" to be the "number of blocks added after it", then SPV essentially trusts that a transaction X blocks deep will be costly to forge.<br />
<br />
This is very different from the trust model in the "thick" client: the thick client verifies that a transaction's inputs are unspent by actually checking the whole chain up to that point -- there is no "X blocks deep" involved here. At that point it uses "X blocks deep" to decide how likely it is that a longer fork in the chain will emerge which excludes that transaction.<br />
<br />
<br />
==== [[BitCoinJ|bitcoinj]] ====<br />
<br />
Simplified Payment Verification is the verification mechanism used in [[BitCoinJ|bitcoinj]].<br />
<br />
A security analysis of some of the issues in bitcoinj can be found [http://code.google.com/p/bitcoinj/wiki/SecurityModel here]; however:<br />
<br />
* The claim that "picking 10 nodes and requiring all of them to be consistent needs much less trust" overlooks the problem of [https://en.bitcoin.it/wiki/Weaknesses#Cancer_nodes "cancer nodes"] and [http://en.wikipedia.org/wiki/Sybil_attack Sybil attacks].<br />
* Many of the security claims are qualified by some form of "if you don't think an attacker controls your internet connection"; see the previous section for a discussion of why this is problematic.<br />
<br />
==== [https://bitcointalk.org/index.php?topic=128055.0 picocoin] ====<br />
<br />
Simplified Payment Verification is the verification mechanism used in picocoin.<br />
<br />
The library (libccoin) that picocoin is based on includes code for validating scripts and blocks; this could potentially be used to implement a full-chain client.<br />
<br />
==== [[Electrum]] ====<br />
<br />
Electrum fetches blockchain information from Electrum servers, bitcoin nodes that index the blockchain by address.<br />
Electrum performs Simple Payment Verification to check the transactions returned by servers.<br />
For this, it fetches blokchain headers from about 10 random servers.<br />
In addition, Electrum servers are authenticated by SSL, in order to protect users from MITM attacks.<br />
<br />
=== Unused Output Tree in the Block chain (UOT) ===<br />
<br />
There have been several proposals (the first appears to be [https://bitcointalk.org/index.php?topic=21995.0 this one] by gmaxwell, who called it an "open transaction tree", although the term "open" is now taken to mean "not yet mined into the block chain" rather than "unspent") to form a tree of unused transaction outputs at each block in the chain, hash it as a Merkle tree, and encode the root hash in the block chain (probably as part of the coinbase input). This will be called an Unused Output Tree (UOT). The first detailed proposal so far appears to be [https://en.bitcoin.it/wiki/User:DiThi/MTUT Alberto Torres' proposal]; etotheipi's [https://bitcointalk.org/index.php?topic=88208.0 ultimate block chain compression] is a variant of this.<br />
<br />
If such UOT hashes were included in the block chain, a client which shipped with a [https://en.bitcoin.it/wiki/Vocabulary checkpoint] block that had a UOT would only need to download blocks after the checkpoint. Moreover, once the client had downloaded those blocks and confirmed their UOTs, it could discard all but the most recent block containing a UOT.<br />
<br />
Hostile miners may insert blocks into the chain which have what claims to be a UOT, but which is actually invalid. It is unlikely that such blocks could be kept out of the chain because, again, this would require adding a new block validity criterion, and miners implementing this new criterion would risk "mining on the wrong side" of a fork, which could cost them a lot of money. Therefore, any UOT strategy would need to cope with the fact that not every block containing a UOT entry can be trusted.<br />
<br />
Note that at the present moment no standard format for such Unused Output Tree hashes has been agreed upon, nor do any of the blocks in the chain contain them. The [https://bitcointalk.org/index.php?topic=91954 ultraprune] feature added to bitcoind-0.8 maintains a similar data structure on the client's disk. It does not put this data structure or its hash anywhere in the block chain.<br />
<br />
== Server-Trusting Clients ==<br />
<br />
These clients involve a high level of trust in the server they rely upon. Mechanisms for authenticating the server, and for confirming that the server has not been compromised, are usually not explained.<br />
<br />
All thin clients listed below currently connect to a single server, and are vulnerable to an attack similar to a double-spend. The attack can be run by that single server - the server can just lie to them that they received a Bitcoin transaction, and they, assuming the server does not lie, perform some service, transfer funds or send goods without actually receiving any Bitcoin in exchange. Therefore, they are implicitly trusting it.<br />
<br />
Future enhancements have been suggested that will have the client talk to multiple servers and broadcast transactions and query all of them. Unfortunately it is well known to security researchers that this does not actually increase security; it simply makes the exploits more complicated and difficult to find. Security researchers have a name for this phenomenon: it is called a "Sybil attack"<ref>http://en.wikipedia.org/wiki/Sybil_attack</ref>. [https://bitcointalk.org/index.php?topic=88208.msg975201#msg975201 This post] on bitcointalk explains how some governments (notably Iran and China) already perform these sorts of attacks on their own citizens, with the coerced assistance of SSL certificate authorities.<br />
<br />
Clients with a checkpoint (even a very old one) that download and validate the headers for the whole block chain are [http://bitcoinmedia.com/the-irc-bootstrap-method-is-flawed/#comment-4243 not vulnerable] to Sybil attacks in the following sense: they can always ensure that an attack would cost more than the amount being stolen.<br />
<br />
=== [[BCCAPI]] ===<br />
<br />
== Other ==<br />
<br />
* A [http://sourceforge.net/mailarchive/message.php?msg_id=28633866 thread] on bitcoin-dev<br />
* A [http://bitcoin.stackexchange.com/questions/2584/is-reclaiming-disk-space-already-implemented-how-effective-will-it-be/2589 question] on bitcoin.stackexchange.com<br />
* The [[Weaknesses#Sybil_attack|sybil attack (also known as "cancer nodes")]] paragraph explains some of the issues with thin clients that base security on trusting whatever "a majority of the IP addresses I can see" say.<br />
* [http://bitcoin.stackexchange.com/questions/2613/how-secure-are-various-models-of-bitcoin-clients related discussion on Stack Exchange]<br />
* A hypothesized [https://bitcointalk.org/index.php?topic=134318.msg1441171#msg1441171 intermediate security class] between SPV and full-chain validation.<br />
<br />
<references><br />
<br />
[[Category:Technical]]<br />
[[category:Clients]]<br />
[[Category:Security]]</div>Lapp0https://en.bitcoin.it/w/index.php?title=Paper_wallet&diff=54797Paper wallet2015-03-02T06:23:50Z<p>Lapp0: Removed websites promoting and using bad practices</p>
<hr />
<div>[[File:FirstBitcoinBills.jpg|thumb|right|200px|Casascius holding early paper wallets]]<br />
<br />
In the most specific sense, a '''paper wallet''' is a document containing all of the data necessary to generate any number of Bitcoin [[private key]]s, forming a wallet of keys. However, people often use the term to mean ''any'' way of storing bitcoins offline as a physical document. This second definition also includes '''paper keys''' and '''redeemable codes'''. A paper key is a single key written on paper that is used multiple times like a wallet (this is strongly [[address reuse|discouraged]]). A redeemable code is a single key intended to be funded and "redeemed" only once: these are commonly used for gifts and as part of physical Bitcoin coins/notes.<br />
<br />
Storing bitcoins on paper wallets is not safe unless very strict security precautions are undertaken during their initial preparation. (See below.)<br />
<br />
__TOC__<br />
<br />
==Use cases==<br />
<br />
===Tips and gifts===<br />
<br />
By creating a keypair, one can store bitcoins on a physical medium to be left as a tip or a gift.<br />
The recipient then sweeps the private key to their own wallet.<br />
<br />
===Physical tokens===<br />
<br />
A trusted provider can hide the private key inside a tamper-resistant token, and issue them as a form of bitcoins.<br />
This requires those who accept it as payment to trust that when the provider produced the tokens, they loaded them with the correct amount of bitcoins, and that they have not been tampered with since then.<br />
To redeem the bitcoin value, the token must be destroyed to access the private key.<br />
Often a bitcoin address is embedded on the outside visible, but there is no guarantee (without destroying the token) that this matches the private key inside, or, even if it does, that the private key is not replicated on multiple tokens or saved by the producer.<br />
<br />
===Wallets===<br />
<br />
Proper paper wallets are often a very secure way of storing bitcoins, since they are not typically exposed to malware. They can also be easily stored securely in safes and safe deposit boxes. However, it may be more difficult to securely "backup" paper wallets, and due to the current sub-optimal software support, it may be easier to make a mistake that causes loss of bitcoins.<br />
<br />
Sometimes people try to use single keys as true bitcoin wallets. However [[address reuse]] is very bad for privacy and security. Because of this, one is forced to choose between hazardous options:<br />
* '''Use the key only once to receive, and only once to send the full amount.''' This requires the user to know the full amount he wants to store in advance, and often leads to the next situation:<br />
* '''Create multiple keys.''' By using more than one key, the user can receive more than once using a different address each time, including using new addresses for change. This is very complicated, and makes it easy to accidentally reuse addresses, produce the wrong change/fee combination, lose some keys, spend hours searching for the right key, etc. Not even skilled bitcoin experts are comfortable managing their own keys manually like this.<br />
<br />
Therefore, it is highly recommended that you use proper paper wallets which allow you to generate an infinite number of addresses from a single seed.<br />
<br />
==Encoding/formatting==<br />
<br />
[[File:BitcoinPaperWallet-sample.jpg|thumb|right|300px|Paper keypair with private key secured beneath folds]]<br />
[[File:PaperWallets-offlineaddress-com.png|200px|thumb|right|Paper keypair]]<br />
Proper, multi-key paper wallets usually take the form of a multi-word [[Deterministic wallet | HD wallet]] seed mnemonic. The list of several words corresponds to some binary data that is used to generate all of the addresses. Words are used to make it easier to avoid and correct errors. Trying to memorize an entire seed mnemonic is very difficult and is generally not recommended.<br />
<br />
A single key (for use in insecure single-key paper wallets or redeemable codes) can be represented in several formats, but typically the Wallet Import Format (WIF) is used, since keys represented that way are very short (51 characters) and thus easy to re-enter when importing or "sweeping" it for withdrawal.<br />
<br />
==Creation of a paper wallet==<br />
<br />
===Generation of secure keys===<br />
<br />
The private seed is used to prove your right to spend the bitcoins transferred to the paper wallet, and as such should be kept hidden and secret.<br />
If the private seed on a paper wallet is exposed (for example in a photograph) then the wallet may be used by anyone who sees it.<br />
To guard against accidental revelation, the private key displayed on the paper wallet may be encrypted or split into several different parts (for example using [https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing Shamir's secret sharing scheme]).<br />
At the very least, the private key should be well hidden e.g. by folding the wallet in half and sealing it shut.<br />
<br />
Currently, at least [[Armory]] and [[Electrum]] support generating mnemonic codes for their wallets, which can be written down or printed to make a multi-key paper wallet.<br />
<br />
Several tools exist for producing single keys, including [[Bitcoin Address Utility]], [[vanitygen]], and [[Cwallet]]. Again, using single keys for anything except one-time ''transfers'' of bitcoins is strongly [[address reuse|discouraged]].<br />
<br />
===Web-based key generators===<br />
<br />
Some websites feature free open-source client-side keypair/wallet generators written in JavaScript.<br />
Keypairs/wallets generated by JavaScript or using websites are inherently weak and insecure, and unless the code of the website is audited every time it is used, it may leak the generated keys back to the server—especially if un-audited Javascript is downloaded and run locally.<br />
Even with careful code auditing, browser plugins or other websites may compromise the environment.<br />
<br />
===Recommendations===<br />
* Disconnecting from the Internet guarantees that that the paper wallet generator is truly self-contained and isn't transmitting your keys online. <br />
* Verifying the integrity of the code (and the trustworthiness of the author) is important to make sure a hacker hasn't modified the download so that it generates predictable seeds instead of truly random ones.<br />
* Remember, spyware and viruses often attempt to monitor your computer activities so that their authors can steal from you. They are interested in passwords to online accounts, and anything of value. Bitcoin wallets are something of value that have already been targeted by malware. If your computer is infected with spyware or viruses - even if there are no symptoms, or your antivirus isn't reporting anything - then anything you type, view, or save on your computer, could potentially be stolen by someone remotely controlling your computer. Your private seed can then be intercepted while you enter it, so only enter a Bitcoin private seed into your computer when you are certain it is secure (such as a fresh boot of a LiveCD).<br />
* The wallet should never be saved to a computer hard drive or sent via email or other network connections. You should also never scan/type your key into your computer, except at the moment you are using it.<br />
* If possible, the wallet should be kept hidden, for example by using BIP38 encryption (single keys only), and/or by folding the paper to hide the private key so that a photograph or photocopy of it will not reveal or replicate the private key.<br />
* A web-based generator should not be used.<br />
* A generator should use an appropriate source of random numbers (entropy). This means that the generated keys aren't predictable. If the addresses come from a predictable or partially-predictable patterns like pseudorandom numbers <ref>[https://en.wikipedia.org/wiki/Pseudorandomness#Cryptography Pseudorandomness] '' is not enough for strong cryptography''</ref>, someone else who can predict the pattern can steal the balance. Randomness should NEVER be human generated, as the human brain is incapable of secure entropy.<br />
* Remember that unlike wallets (paper or otherwise), a single paper key is only good to receive a single payment, and must be redeemed in its entirety.<br />
<br />
===Printer Security===<br />
<br />
Some advanced printers have internal storage (even hard drives) that preserve copies of printouts. This is a risk if someone gets access to your printer, or if you dispose of your printer. There is also the possibility that a smart enough printer can be hacked. (Consider [http://en.wikipedia.org/wiki/Stuxnet StuxNet] which was able to rewrite the firmware of non-computer devices indirectly connected to the Internet) If this concerns you, use a "dumb" printer, and never let your printer have access to the Internet or to an Internet-connected computer.<br />
<br />
==Redeeming Keys and Withdrawing Funds==<br />
<br />
This section applies only to single-key paper "wallets".<br />
<br />
Paper keys, when used as wallets, are very different from wallets such as Bitcoin Core in that it is not possible to transfer (withdraw) a ''portion'' of a key's bitcoins.<br />
The only way to withdraw funds is to import or "sweep" the ''entire'' received amount to a new address, typically a wallet or online exchange.<br />
Once the transfer has been confirmed, ''the key should not be reused''.<ref>[http://www.reddit.com/r/Bitcoin/comments/1c9xr7/psa_using_paper_wallets_understanding_change/ reddit.com] ''Using Paper Wallets and Understanding Change''</ref><br />
<br />
There are various methods for copying the private key data to other wallets.<br />
* bitcoind supports an "importprivkey" RPC method for this purpose.<br />
* Bitcoin-Qt's debug console can also be used in a similar way (see also [[How to import private keys in Bitcoin Core 0.7+]]).<br />
* [[BlockChain.info]] and [[Armory]] can also import them directly into wallets.<br />
* [http://MyCelium.com/download Mycelium] is a Android mobile wallet with an easy to use "cold storage" spending function. It is also available via Android and iTunes playstore. The iTunes version may not yet support cold storage spending.<br />
<br />
Note that importing a private key that may be compromised can result in the entire wallet becoming insecure.<br />
For this reason, sweeping is generally recommended over importing.<br />
<br />
==References==<br />
<references /><br />
<br />
==See Also==<br />
<br />
* [[Private key]]<br />
<br />
* [[Securing_your_wallet#Paper_Wallets]]<br />
<br />
* [[How to import private keys]]<br />
<br />
* [https://blockchain.info/wallet/paper-tutorial Blockchain.info tutorial] on how to generate a paper wallet.<br />
<br />
* [[Casascius physical bitcoins]]<br />
<br />
[[Category:Security]]<br />
<br />
[[es:Monedero de papel]]</div>Lapp0https://en.bitcoin.it/w/index.php?title=Talk:Thin_Client_Security&diff=54743Talk:Thin Client Security2015-02-28T18:17:20Z<p>Lapp0: formatting</p>
<hr />
<div>Lapp0, please stop deleting my content, which has been on this wiki page for over three years now. If you think it's suddenly no longer true, discuss here first. In particular, you wrote:<br />
<br />
Transactions don't become more valid with more block preceding it's proof.<br />
<br />
Chains become more trustworthy as they become (difficultywise-)longer. This is the most basic principle of blockchain consensus.<br />
<br />
I have to keep putting that "(difficultywise-)" in there so pedantic people don't pounce on me... a 100,000-block chain all at difficulty=1 is "difficultywise-shorter" than a 100-block chain at current difficulty levels (or a one-block chain for that matter). It's not the number of blocks, but their total difficulty.<br />
<br />
You also wrote:<br />
<br />
The vagueness of what Full-chain is should be elaborated on probably explaining it uses SPV proofs<br />
<br />
No, full-chain clients such as the Satoshi client do not use SPV in any way, shape, or form. A full-chain client is a client that implements the main algorithm outlined in Satoshi's whitepaper.<br />
<br />
[[User:Eldentyrell|Eldentyrell]] ([[User talk:Eldentyrell|talk]]) 03:05, 26 February 2015 (UTC)<br />
<br />
:This page looks very confused/wrong in many respects. I'm not sure how it can be fixed easily, since it is unclear what exactly it intends to say.<br />
:* Generally "thin clients" do not include pruned full nodes, which have processed every block, but afterward discarded (and no longer store) them.<br />
:* Even thin clients generally verify block heights as well as depth.<br />
:* Thin clients never (neither for height nor depth) check blocks are valid ("well-formed"?). This is the fundamental difference between full nodes vs thin clients.<br />
:* Transaction validity is independent of its inclusion in any blockchain.<br />
:--[[User:Luke-jr|Luke-jr]] ([[User talk:Luke-jr|talk]]) 07:58, 26 February 2015 (UTC)<br />
<br />
<br />
::Luke, thanks for your thoughts. Regarding your points,<br />
<br />
::* Good point, I have partitioned "full-chain" into two separate subtypes (those which do and those which don't retain blocks after validating)<br />
::* SPV clients do not verify block height. I can take the existing 345308-block bitcoin blockchain, append a single block that re-spends coins I sent two years ago, and use that 345309-block chain to fool an SPV client. By wasting hashpower whose market value is as most one block reward I can fool an SPV client with it, since it will appear to be the difficultywise-longest chain by one block. I cannot fool the Satoshi client this way even with the hashpower of the entire network at my disposal.<br />
::* True. I think you may have hastily misread "transaction validity" as "block validity".<br />
::* True. I think you may have hastily misread "transaction validity" as "block validity".<br />
<br />
::Thanks again!<br />
<br />
::[[User:Eldentyrell|Eldentyrell]] ([[User talk:Eldentyrell|talk]]) 23:14, 26 February 2015 (UTC)<br />
<br />
:::* Since this article deals with security, I do not think the distinction between pruned vs non-pruned is relevant - both nodes have equal security implications.<br />
:::* SPV nodes are aware that your invalid 345309th block has a height higher than any other chain, and thus verify the block height before considering that chain ::;"best". They do not, as you mention, validate the contents of any of those blocks, and can be fooled this way, but that is unrelated to the block's height.<br />
:::* I was referring to the statement that "the validity of a transaction is determined by its height", which is simply not true. A transaction is valid before and even if it is never mined.<br />
:::--[[User:Luke-jr|Luke-jr]] ([[User talk:Luke-jr|talk]]) 01:42, 27 February 2015 (UTC)<br />
<br />
<br />
:::;* Ok<br />
:::;* Ah, now I see why we disagree: I don't consider the last block of an ill-formed chain of 345309 blocks to be "of height 345309".<br />
<br />
::::Is there a term other than "height X" you would recommend in order to describe the property of being the Xth block of a completely well-formed blockchain that obeys all the block validation rules (particularly no double-spends)? This is the property that SPV clients are not able to check. If there is a better name for this property I'll rewrite that section to use it.<br />
<br />
::::I think the other issue here is my use of the term "valid transaction". I've been using that to describe a transaction that has been accepted by the network and that clients can safely assume is irreversible. I guess that term is sort of ambiguous; I can see how it could also be used to describe mempool transactions that aren't yet part of any block but could legitimately be included in the next one. What is the generally-accepted adjective for in-the-chain-and-safe-to-assume-is-totally-irreversible? I've substituted "accepted transaction" in the article where that was the intended meaning, but if there's a more widely-used phrase let me know. I also made a second edit to separate out "acceptance" from "degree of irreversibility" since "degree of irreversibility" is always measured the same way by all kinds of clients (number of confirmations, i.e. depth).<br />
<br />
::::[[User:Eldentyrell|Eldentyrell]] ([[User talk:Eldentyrell|talk]]) 06:02, 28 February 2015 (UTC)<br />
<br />
:::::I've always considered "the Nth block of a blockchain" to be an independent property from the validity of the blockchain. I'm not aware of any common term for this, but "height N" isn't generally used in that sense (although in most cases it's implied that one is talking about a valid blockchain, regardless of the height property). As for contrasting with SPV, I would suggest "fully-validat{ed,ing}" or "full node".<br />
<br />
:::::When a user assumes a transaction is confirmed/irreversible is a subjective matter, and may be before the block is mined if they trust the sender or it's of low value, or long afterward if they don't trust the mining ecosystem's balance or the value is such that they need more security. So I think the term you want there is "confirmed", but it's not a universally objective attribute.<br />
<br />
:::::--[[User:Luke-jr|Luke-jr]] ([[User talk:Luke-jr|talk]]) 07:07, 28 February 2015 (UTC)<br />
<br />
<br />
:Full-chain is not well defined and isn't common terminology. If you are saying the Satoshi client is full-chain, then you probably mean full node. "full network node" or "full node" is common terminology and is used in the original Bitcoin whitepaper.<br />
<br />
:Your definition of transaction validity isn't common and is even incompatible with the Bitcoin whitepaper.<br />
<br />
:You added "A full-chain client trusts the [[Protocol_rules#Blocks well-formed|difficultywise-longest]] block chain it can find." which is only true for SPV clients, so you can see why I would be confused as to what this poorly defined "full-chain" client does.<br />
<br />
:I don't think the bitcoin wiki is an appropriate place to redefine terminology.<br />
<br />
:Finally, I am not deleting your content, I am deleting the wikis content because it is wrong. Please stop blindly reverting my edits, you removing spelling corrections indicates that you don't care about the accuracy of the wiki as much as maximizing the amount of text written by you on the wiki.<br />
:--[[User:Lapp0|Lapp0]] ([[User talk:Lapp0|talk]])<br />
<br />
== Major Restructuring ==<br />
<br />
This page was riddled with incorrect uses of words and the creation of new terminology. This leaves the reader confused or mislead. I have restructured this page and attempted to remove most of the inaccurate parts. It's not that I "think it's suddenly no longer true", I know that it hasn't been true for three years and no one has caught it until now.<br />
<br />
--[[User:Lapp0|Lapp0]] ([[User talk:Lapp0|talk]])<br />
<br />
:If you continue to add nonsense to the article and don't discuss it here (especially when you add 2000+ characters of incorrect information where the note implies it is a minor edit), I will continue to revert. --[[User:Lapp0|Lapp0]] ([[User talk:Lapp0|talk]])</div>Lapp0https://en.bitcoin.it/w/index.php?title=Thin_Client_Security&diff=54742Thin Client Security2015-02-28T18:15:21Z<p>Lapp0: typo</p>
<hr />
<div>Recently there have been a number of proposals for bitcoin clients which do not store a complete copy of every block in the entire block chain. This page will refer to all such clients as "thin clients". This page is meant to be a place to try to make sense of the security and trust implications of the various schemes.<br />
<br />
== Full Node vs. SPV ==<br />
<br />
It is important to distinguish between block height verification and block depth verification.<br />
<br />
A full node client verifies that all preceding blocks are valid in order to guarantee that a transaction is valid. Currently only the Satoshi client, libbitcoin, and btcd do full node verification. Full nodes are the fundamental anchor of trustless security in the Bitcoin system.<br />
<br />
A client verifies the depth D of a block by checking that there are D blocks '''after''' it (also called "confirmations"), all of which are well-formed. SPV clients don't verify the preceding blocks, they use the number of confirmations (whether they are valid or not) as a measure of the likelihood of a [[Chain_Reorganization|block chain reorganization]] producing a new longer fork which excludes the transaction.<br />
<br />
See also [https://bitcointalk.org/index.php?topic=88208.msg987429#msg987429 some comments on probabilistic verification of block height].<br />
<br />
== Full Node Clients ==<br />
<br />
The "thick" bitcoin client downloads a copy of the entire chain, including all transactions (not just headers). It will be used as the reference point for security comparisons below.<br />
<br />
A full-node client uses the [[Protocol_rules#Blocks well-formed|difficultywise-longest]] valid block chain it can find. A transaction's ''depth'' (the number of blocks or confirmations ''after'' it) is used to determine the likelihood of the transaction being double-spent due to the emergence of a longer fork.<br />
<br />
==== [[bitcoind|bitcoin-qt]] ====<br />
<br />
==== [https://github.com/conformal/btcd btcd] ====<br />
<br />
=== Block Retention ===<br />
<br />
Once a full-chain client has downloaded the entire chain, it typically retains it (as the Satoshi client did/does).<br />
<br />
Satoshi's original paper mentions the possibility of pruning individual transactions, which allows for full nodes which verify the entire transaction history but do not retain it. Because users are required to download and verify the block chain from some other node initially, this change isn't costless.<br />
<br />
<br />
== Simplified Payment Verification (SPV) Clients ==<br />
<br />
This client downloads a complete copy of the headers for all blocks in the entire block chain. This means that the download and storage requirements scale linearly with the amount of time since Bitcoin was invented.<br />
<br />
This scheme is described in section 8 of the [http://bitcoin.org/bitcoin.pdf original bitcoin whitepaper].<br />
<br />
==== Block Depth Check ====<br />
<br />
As Satoshi writes, "[the thin client] can't check the transaction for himself, but by linking it to a place in the chain, he can see that a network node has accepted it, and blocks added after it further confirm the network has accepted it." If we take "X" to be the "number of blocks added after it", then SPV essentially trusts that a transaction X blocks deep will be costly to forge.<br />
<br />
This is very different from the trust model in the "thick" client: the thick client verifies that a transaction's inputs are unspent by actually checking the whole chain up to that point -- there is no "X blocks deep" involved here. At that point it uses "X blocks deep" to decide how likely it is that a longer fork in the chain will emerge which excludes that transaction.<br />
<br />
<br />
==== [[BitCoinJ|bitcoinj]] ====<br />
<br />
Simplified Payment Verification is the verification mechanism used in [[BitCoinJ|bitcoinj]].<br />
<br />
A security analysis of some of the issues in bitcoinj can be found [http://code.google.com/p/bitcoinj/wiki/SecurityModel here]; however:<br />
<br />
* The claim that "picking 10 nodes and requiring all of them to be consistent needs much less trust" overlooks the problem of [https://en.bitcoin.it/wiki/Weaknesses#Cancer_nodes "cancer nodes"] and [http://en.wikipedia.org/wiki/Sybil_attack Sybil attacks].<br />
* Many of the security claims are qualified by some form of "if you don't think an attacker controls your internet connection"; see the previous section for a discussion of why this is problematic.<br />
<br />
==== [https://bitcointalk.org/index.php?topic=128055.0 picocoin] ====<br />
<br />
Simplified Payment Verification is the verification mechanism used in picocoin.<br />
<br />
The library (libccoin) that picocoin is based on includes code for validating scripts and blocks; this could potentially be used to implement a full-chain client.<br />
<br />
==== [[Electrum]] ====<br />
<br />
Electrum fetches blockchain information from Electrum servers, bitcoin nodes that index the blockchain by address.<br />
Electrum performs Simple Payment Verification to check the transactions returned by servers.<br />
For this, it fetches blokchain headers from about 10 random servers.<br />
In addition, Electrum servers are authenticated by SSL, in order to protect users from MITM attacks.<br />
<br />
=== Unused Output Tree in the Block chain (UOT) ===<br />
<br />
There have been several proposals (the first appears to be [https://bitcointalk.org/index.php?topic=21995.0 this one] by gmaxwell, who called it an "open transaction tree", although the term "open" is now taken to mean "not yet mined into the block chain" rather than "unspent") to form a tree of unused transaction outputs at each block in the chain, hash it as a Merkle tree, and encode the root hash in the block chain (probably as part of the coinbase input). This will be called an Unused Output Tree (UOT). The first detailed proposal so far appears to be [https://en.bitcoin.it/wiki/User:DiThi/MTUT Alberto Torres' proposal]; etotheipi's [https://bitcointalk.org/index.php?topic=88208.0 ultimate block chain compression] is a variant of this.<br />
<br />
If such UOT hashes were included in the block chain, a client which shipped with a [https://en.bitcoin.it/wiki/Vocabulary checkpoint] block that had a UOT would only need to download blocks after the checkpoint. Moreover, once the client had downloaded those blocks and confirmed their UOTs, it could discard all but the most recent block containing a UOT.<br />
<br />
Hostile miners may insert blocks into the chain which have what claims to be a UOT, but which is actually invalid. It is unlikely that such blocks could be kept out of the chain because, again, this would require adding a new block validity criterion, and miners implementing this new criterion would risk "mining on the wrong side" of a fork, which could cost them a lot of money. Therefore, any UOT strategy would need to cope with the fact that not every block containing a UOT entry can be trusted.<br />
<br />
Note that at the present moment no standard format for such Unused Output Tree hashes has been agreed upon, nor do any of the blocks in the chain contain them. The [https://bitcointalk.org/index.php?topic=91954 ultraprune] feature added to bitcoind-0.8 maintains a similar data structure on the client's disk. It does not put this data structure or its hash anywhere in the block chain.<br />
<br />
== Server-Trusting Clients ==<br />
<br />
These clients involve a high level of trust in the server they rely upon. Mechanisms for authenticating the server, and for confirming that the server has not been compromised, are usually not explained.<br />
<br />
All thin clients listed below currently connect to a single server, and are vulnerable to an attack similar to a double-spend. The attack can be run by that single server - the server can just lie to them that they received a Bitcoin transaction, and they, assuming the server does not lie, perform some service, transfer funds or send goods without actually receiving any Bitcoin in exchange. Therefore, they are implicitly trusting it.<br />
<br />
Future enhancements have been suggested that will have the client talk to multiple servers and broadcast transactions and query all of them. Unfortunately it is well known to security researchers that this does not actually increase security; it simply makes the exploits more complicated and difficult to find. Security researchers have a name for this phenomenon: it is called a "Sybil attack"<ref>http://en.wikipedia.org/wiki/Sybil_attack</ref>. [https://bitcointalk.org/index.php?topic=88208.msg975201#msg975201 This post] on bitcointalk explains how some governments (notably Iran and China) already perform these sorts of attacks on their own citizens, with the coerced assistance of SSL certificate authorities.<br />
<br />
Clients with a checkpoint (even a very old one) that download and validate the headers for the whole block chain are [http://bitcoinmedia.com/the-irc-bootstrap-method-is-flawed/#comment-4243 not vulnerable] to Sybil attacks in the following sense: they can always ensure that an attack would cost more than the amount being stolen.<br />
<br />
=== [[BCCAPI]] ===<br />
<br />
== Other ==<br />
<br />
* A [http://sourceforge.net/mailarchive/message.php?msg_id=28633866 thread] on bitcoin-dev<br />
* A [http://bitcoin.stackexchange.com/questions/2584/is-reclaiming-disk-space-already-implemented-how-effective-will-it-be/2589 question] on bitcoin.stackexchange.com<br />
* The [[Weaknesses#Sybil_attack|sybil attack (also known as "cancer nodes")]] paragraph explains some of the issues with thin clients that base security on trusting whatever "a majority of the IP addresses I can see" say.<br />
* [http://bitcoin.stackexchange.com/questions/2613/how-secure-are-various-models-of-bitcoin-clients related discussion on Stack Exchange]<br />
* A hypothesized [https://bitcointalk.org/index.php?topic=134318.msg1441171#msg1441171 intermediate security class] between SPV and full-chain validation.<br />
<br />
<references><br />
<br />
[[Category:Technical]]<br />
[[category:Clients]]<br />
[[Category:Security]]</div>Lapp0https://en.bitcoin.it/w/index.php?title=Talk:Thin_Client_Security&diff=54741Talk:Thin Client Security2015-02-28T18:11:59Z<p>Lapp0: /* Major Restructuring */</p>
<hr />
<div>Lapp0, please stop deleting my content, which has been on this wiki page for over three years now. If you think it's suddenly no longer true, discuss here first. In particular, you wrote:<br />
<br />
Transactions don't become more valid with more block preceding it's proof.<br />
<br />
Chains become more trustworthy as they become (difficultywise-)longer. This is the most basic principle of blockchain consensus.<br />
<br />
I have to keep putting that "(difficultywise-)" in there so pedantic people don't pounce on me... a 100,000-block chain all at difficulty=1 is "difficultywise-shorter" than a 100-block chain at current difficulty levels (or a one-block chain for that matter). It's not the number of blocks, but their total difficulty.<br />
<br />
You also wrote:<br />
<br />
The vagueness of what Full-chain is should be elaborated on probably explaining it uses SPV proofs<br />
<br />
No, full-chain clients such as the Satoshi client do not use SPV in any way, shape, or form. A full-chain client is a client that implements the main algorithm outlined in Satoshi's whitepaper.<br />
<br />
[[User:Eldentyrell|Eldentyrell]] ([[User talk:Eldentyrell|talk]]) 03:05, 26 February 2015 (UTC)<br />
<br />
This page looks very confused/wrong in many respects. I'm not sure how it can be fixed easily, since it is unclear what exactly it intends to say.<br />
* Generally "thin clients" do not include pruned full nodes, which have processed every block, but afterward discarded (and no longer store) them.<br />
* Even thin clients generally verify block heights as well as depth.<br />
* Thin clients never (neither for height nor depth) check blocks are valid ("well-formed"?). This is the fundamental difference between full nodes vs thin clients.<br />
* Transaction validity is independent of its inclusion in any blockchain.<br />
--[[User:Luke-jr|Luke-jr]] ([[User talk:Luke-jr|talk]]) 07:58, 26 February 2015 (UTC)<br />
<br />
<br />
Luke, thanks for your thoughts. Regarding your points,<br />
<br />
* Good point, I have partitioned "full-chain" into two separate subtypes (those which do and those which don't retain blocks after validating)<br />
* SPV clients do not verify block height. I can take the existing 345308-block bitcoin blockchain, append a single block that re-spends coins I sent two years ago, and use that 345309-block chain to fool an SPV client. By wasting hashpower whose market value is as most one block reward I can fool an SPV client with it, since it will appear to be the difficultywise-longest chain by one block. I cannot fool the Satoshi client this way even with the hashpower of the entire network at my disposal.<br />
* True. I think you may have hastily misread "transaction validity" as "block validity".<br />
* True. I think you may have hastily misread "transaction validity" as "block validity".<br />
<br />
Thanks again!<br />
<br />
[[User:Eldentyrell|Eldentyrell]] ([[User talk:Eldentyrell|talk]]) 23:14, 26 February 2015 (UTC)<br />
<br />
* Since this article deals with security, I do not think the distinction between pruned vs non-pruned is relevant - both nodes have equal security implications.<br />
* SPV nodes are aware that your invalid 345309th block has a height higher than any other chain, and thus verify the block height before considering that chain "best". They do not, as you mention, validate the contents of any of those blocks, and can be fooled this way, but that is unrelated to the block's height.<br />
* I was referring to the statement that "the validity of a transaction is determined by its height", which is simply not true. A transaction is valid before and even if it is never mined.<br />
--[[User:Luke-jr|Luke-jr]] ([[User talk:Luke-jr|talk]]) 01:42, 27 February 2015 (UTC)<br />
<br />
<br />
* Ok<br />
* Ah, now I see why we disagree: I don't consider the last block of an ill-formed chain of 345309 blocks to be "of height 345309".<br />
<br />
Is there a term other than "height X" you would recommend in order to describe the property of being the Xth block of a completely well-formed blockchain that obeys all the block validation rules (particularly no double-spends)? This is the property that SPV clients are not able to check. If there is a better name for this property I'll rewrite that section to use it.<br />
<br />
I think the other issue here is my use of the term "valid transaction". I've been using that to describe a transaction that has been accepted by the network and that clients can safely assume is irreversible. I guess that term is sort of ambiguous; I can see how it could also be used to describe mempool transactions that aren't yet part of any block but could legitimately be included in the next one. What is the generally-accepted adjective for in-the-chain-and-safe-to-assume-is-totally-irreversible? I've substituted "accepted transaction" in the article where that was the intended meaning, but if there's a more widely-used phrase let me know. I also made a second edit to separate out "acceptance" from "degree of irreversibility" since "degree of irreversibility" is always measured the same way by all kinds of clients (number of confirmations, i.e. depth).<br />
<br />
[[User:Eldentyrell|Eldentyrell]] ([[User talk:Eldentyrell|talk]]) 06:02, 28 February 2015 (UTC)<br />
<br />
I've always considered "the Nth block of a blockchain" to be an independent property from the validity of the blockchain. I'm not aware of any common term for this, but "height N" isn't generally used in that sense (although in most cases it's implied that one is talking about a valid blockchain, regardless of the height property). As for contrasting with SPV, I would suggest "fully-validat{ed,ing}" or "full node".<br />
<br />
When a user assumes a transaction is confirmed/irreversible is a subjective matter, and may be before the block is mined if they trust the sender or it's of low value, or long afterward if they don't trust the mining ecosystem's balance or the value is such that they need more security. So I think the term you want there is "confirmed", but it's not a universally objective attribute.<br />
<br />
--[[User:Luke-jr|Luke-jr]] ([[User talk:Luke-jr|talk]]) 07:07, 28 February 2015 (UTC)<br />
<br />
<br />
Full-chain is not well defined and isn't common terminology. If you are saying the Satoshi client is full-chain, then you probably mean full node. "full network node" or "full node" is common terminology and is used in the original Bitcoin whitepaper.<br />
<br />
Your definition of transaction validity isn't common and is even incompatible with the Bitcoin whitepaper.<br />
<br />
You added "A full-chain client trusts the [[Protocol_rules#Blocks well-formed|difficultywise-longest]] block chain it can find." which is only true for SPV clients, so you can see why I would be confused as to what this poorly defined "full-chain" client does.<br />
<br />
I don't think the bitcoin wiki is an appropriate place to redefine terminology.<br />
<br />
Finally, I am not deleting your content, I am deleting the wikis content because it is wrong. Please stop blindly reverting my edits, you removing spelling corrections indicates that you don't care about the accuracy of the wiki as much as maximizing the amount of text written by you on the wiki.<br />
--[[User:Lapp0|Lapp0]] ([[User talk:Lapp0|talk]])<br />
<br />
== Major Restructuring ==<br />
<br />
This page was riddled with incorrect uses of words and the creation of new terminology. This leaves the reader confused or mislead. I have restructured this page and attempted to remove most of the inaccurate parts. It's not that I "think it's suddenly no longer true", I know that it hasn't been true for three years and no one has caught it until now.<br />
<br />
--[[User:Lapp0|Lapp0]] ([[User talk:Lapp0|talk]])<br />
<br />
:If you continue to add nonsense to the article and don't discuss it here (especially when you add 2000+ characters of incorrect information where the note implies it is a minor edit), I will continue to revert. --[[User:Lapp0|Lapp0]] ([[User talk:Lapp0|talk]])</div>Lapp0https://en.bitcoin.it/w/index.php?title=Talk:Thin_Client_Security&diff=54740Talk:Thin Client Security2015-02-28T18:11:42Z<p>Lapp0: /* Major Restructuring */</p>
<hr />
<div>Lapp0, please stop deleting my content, which has been on this wiki page for over three years now. If you think it's suddenly no longer true, discuss here first. In particular, you wrote:<br />
<br />
Transactions don't become more valid with more block preceding it's proof.<br />
<br />
Chains become more trustworthy as they become (difficultywise-)longer. This is the most basic principle of blockchain consensus.<br />
<br />
I have to keep putting that "(difficultywise-)" in there so pedantic people don't pounce on me... a 100,000-block chain all at difficulty=1 is "difficultywise-shorter" than a 100-block chain at current difficulty levels (or a one-block chain for that matter). It's not the number of blocks, but their total difficulty.<br />
<br />
You also wrote:<br />
<br />
The vagueness of what Full-chain is should be elaborated on probably explaining it uses SPV proofs<br />
<br />
No, full-chain clients such as the Satoshi client do not use SPV in any way, shape, or form. A full-chain client is a client that implements the main algorithm outlined in Satoshi's whitepaper.<br />
<br />
[[User:Eldentyrell|Eldentyrell]] ([[User talk:Eldentyrell|talk]]) 03:05, 26 February 2015 (UTC)<br />
<br />
This page looks very confused/wrong in many respects. I'm not sure how it can be fixed easily, since it is unclear what exactly it intends to say.<br />
* Generally "thin clients" do not include pruned full nodes, which have processed every block, but afterward discarded (and no longer store) them.<br />
* Even thin clients generally verify block heights as well as depth.<br />
* Thin clients never (neither for height nor depth) check blocks are valid ("well-formed"?). This is the fundamental difference between full nodes vs thin clients.<br />
* Transaction validity is independent of its inclusion in any blockchain.<br />
--[[User:Luke-jr|Luke-jr]] ([[User talk:Luke-jr|talk]]) 07:58, 26 February 2015 (UTC)<br />
<br />
<br />
Luke, thanks for your thoughts. Regarding your points,<br />
<br />
* Good point, I have partitioned "full-chain" into two separate subtypes (those which do and those which don't retain blocks after validating)<br />
* SPV clients do not verify block height. I can take the existing 345308-block bitcoin blockchain, append a single block that re-spends coins I sent two years ago, and use that 345309-block chain to fool an SPV client. By wasting hashpower whose market value is as most one block reward I can fool an SPV client with it, since it will appear to be the difficultywise-longest chain by one block. I cannot fool the Satoshi client this way even with the hashpower of the entire network at my disposal.<br />
* True. I think you may have hastily misread "transaction validity" as "block validity".<br />
* True. I think you may have hastily misread "transaction validity" as "block validity".<br />
<br />
Thanks again!<br />
<br />
[[User:Eldentyrell|Eldentyrell]] ([[User talk:Eldentyrell|talk]]) 23:14, 26 February 2015 (UTC)<br />
<br />
* Since this article deals with security, I do not think the distinction between pruned vs non-pruned is relevant - both nodes have equal security implications.<br />
* SPV nodes are aware that your invalid 345309th block has a height higher than any other chain, and thus verify the block height before considering that chain "best". They do not, as you mention, validate the contents of any of those blocks, and can be fooled this way, but that is unrelated to the block's height.<br />
* I was referring to the statement that "the validity of a transaction is determined by its height", which is simply not true. A transaction is valid before and even if it is never mined.<br />
--[[User:Luke-jr|Luke-jr]] ([[User talk:Luke-jr|talk]]) 01:42, 27 February 2015 (UTC)<br />
<br />
<br />
* Ok<br />
* Ah, now I see why we disagree: I don't consider the last block of an ill-formed chain of 345309 blocks to be "of height 345309".<br />
<br />
Is there a term other than "height X" you would recommend in order to describe the property of being the Xth block of a completely well-formed blockchain that obeys all the block validation rules (particularly no double-spends)? This is the property that SPV clients are not able to check. If there is a better name for this property I'll rewrite that section to use it.<br />
<br />
I think the other issue here is my use of the term "valid transaction". I've been using that to describe a transaction that has been accepted by the network and that clients can safely assume is irreversible. I guess that term is sort of ambiguous; I can see how it could also be used to describe mempool transactions that aren't yet part of any block but could legitimately be included in the next one. What is the generally-accepted adjective for in-the-chain-and-safe-to-assume-is-totally-irreversible? I've substituted "accepted transaction" in the article where that was the intended meaning, but if there's a more widely-used phrase let me know. I also made a second edit to separate out "acceptance" from "degree of irreversibility" since "degree of irreversibility" is always measured the same way by all kinds of clients (number of confirmations, i.e. depth).<br />
<br />
[[User:Eldentyrell|Eldentyrell]] ([[User talk:Eldentyrell|talk]]) 06:02, 28 February 2015 (UTC)<br />
<br />
I've always considered "the Nth block of a blockchain" to be an independent property from the validity of the blockchain. I'm not aware of any common term for this, but "height N" isn't generally used in that sense (although in most cases it's implied that one is talking about a valid blockchain, regardless of the height property). As for contrasting with SPV, I would suggest "fully-validat{ed,ing}" or "full node".<br />
<br />
When a user assumes a transaction is confirmed/irreversible is a subjective matter, and may be before the block is mined if they trust the sender or it's of low value, or long afterward if they don't trust the mining ecosystem's balance or the value is such that they need more security. So I think the term you want there is "confirmed", but it's not a universally objective attribute.<br />
<br />
--[[User:Luke-jr|Luke-jr]] ([[User talk:Luke-jr|talk]]) 07:07, 28 February 2015 (UTC)<br />
<br />
<br />
Full-chain is not well defined and isn't common terminology. If you are saying the Satoshi client is full-chain, then you probably mean full node. "full network node" or "full node" is common terminology and is used in the original Bitcoin whitepaper.<br />
<br />
Your definition of transaction validity isn't common and is even incompatible with the Bitcoin whitepaper.<br />
<br />
You added "A full-chain client trusts the [[Protocol_rules#Blocks well-formed|difficultywise-longest]] block chain it can find." which is only true for SPV clients, so you can see why I would be confused as to what this poorly defined "full-chain" client does.<br />
<br />
I don't think the bitcoin wiki is an appropriate place to redefine terminology.<br />
<br />
Finally, I am not deleting your content, I am deleting the wikis content because it is wrong. Please stop blindly reverting my edits, you removing spelling corrections indicates that you don't care about the accuracy of the wiki as much as maximizing the amount of text written by you on the wiki.<br />
--[[User:Lapp0|Lapp0]] ([[User talk:Lapp0|talk]])<br />
<br />
== Major Restructuring ==<br />
<br />
This page was riddled with incorrect uses of words and the creation of new terminology. This leaves the reader confused or mislead. I have restructured this page and attempted to remove most of the inaccurate parts. It's not that I "think it's suddenly no longer true", I know that it hasn't been true for three years and no one has caught it until now.<br />
<br />
--[[User:Lapp0|Lapp0]] ([[User talk:Lapp0|talk]])<br />
<br />
:If you continue to add nonsense to the article and don't discuss it here (especially when you add 2000+ lines of incorrect information where the note implies it is a minor edit), I will continue to revert. --[[User:Lapp0|Lapp0]] ([[User talk:Lapp0|talk]])</div>Lapp0https://en.bitcoin.it/w/index.php?title=Thin_Client_Security&diff=54739Thin Client Security2015-02-28T18:08:54Z<p>Lapp0: Replace "valid" with "irreversible" where appropriate without adding incorrect statements to the article.</p>
<hr />
<div>Recently there have been a number of proposals for bitcoin clients which do not store a complete copy of every block in the entire block chain. This page will refer to all such clients as "thin clients". This page is meant to be a place to try to make sense of the security and trust implications of the various schemes.<br />
<br />
== Full Node vs. SPV ==<br />
<br />
It is important to distinguish between block height verification and block depth verification.<br />
<br />
A full node client verifies that all preceding blocks are valid in order to guarantee that a transaction is valid. Currently only the Satoshi client, libbitcoin, and btcd do full node verification. Full nodes are the fundamental anchor of trustless security in the Bitcoin system.<br />
<br />
A client verifies the depth D of a block by checking that there are D blocks '''after''' it (also called "confirmations"), all of which are well-formed. SPV don't verify the preceding blocks, they use the number of confirmations (whether they are valid or not) as a measure of the likelihood of a [[Chain_Reorganization|block chain reorganization]] producing a new longer fork which excludes the transaction.<br />
<br />
See also [https://bitcointalk.org/index.php?topic=88208.msg987429#msg987429 some comments on probabilistic verification of block height].<br />
<br />
== Full Node Clients ==<br />
<br />
The "thick" bitcoin client downloads a copy of the entire chain, including all transactions (not just headers). It will be used as the reference point for security comparisons below.<br />
<br />
A full-node client uses the [[Protocol_rules#Blocks well-formed|difficultywise-longest]] valid block chain it can find. A transaction's ''depth'' (the number of blocks or confirmations ''after'' it) is used to determine the likelihood of the transaction being double-spent due to the emergence of a longer fork.<br />
<br />
==== [[bitcoind|bitcoin-qt]] ====<br />
<br />
==== [https://github.com/conformal/btcd btcd] ====<br />
<br />
=== Block Retention ===<br />
<br />
Once a full-chain client has downloaded the entire chain, it typically retains it (as the Satoshi client did/does).<br />
<br />
Satoshi's original paper mentions the possibility of pruning individual transactions, which allows for full nodes which verify the entire transaction history but do not retain it. Because users are required to download and verify the block chain from some other node initially, this change isn't costless.<br />
<br />
<br />
== Simplified Payment Verification (SPV) Clients ==<br />
<br />
This client downloads a complete copy of the headers for all blocks in the entire block chain. This means that the download and storage requirements scale linearly with the amount of time since Bitcoin was invented.<br />
<br />
This scheme is described in section 8 of the [http://bitcoin.org/bitcoin.pdf original bitcoin whitepaper].<br />
<br />
==== Block Depth Check ====<br />
<br />
As Satoshi writes, "[the thin client] can't check the transaction for himself, but by linking it to a place in the chain, he can see that a network node has accepted it, and blocks added after it further confirm the network has accepted it." If we take "X" to be the "number of blocks added after it", then SPV essentially trusts that a transaction X blocks deep will be costly to forge.<br />
<br />
This is very different from the trust model in the "thick" client: the thick client verifies that a transaction's inputs are unspent by actually checking the whole chain up to that point -- there is no "X blocks deep" involved here. At that point it uses "X blocks deep" to decide how likely it is that a longer fork in the chain will emerge which excludes that transaction.<br />
<br />
<br />
==== [[BitCoinJ|bitcoinj]] ====<br />
<br />
Simplified Payment Verification is the verification mechanism used in [[BitCoinJ|bitcoinj]].<br />
<br />
A security analysis of some of the issues in bitcoinj can be found [http://code.google.com/p/bitcoinj/wiki/SecurityModel here]; however:<br />
<br />
* The claim that "picking 10 nodes and requiring all of them to be consistent needs much less trust" overlooks the problem of [https://en.bitcoin.it/wiki/Weaknesses#Cancer_nodes "cancer nodes"] and [http://en.wikipedia.org/wiki/Sybil_attack Sybil attacks].<br />
* Many of the security claims are qualified by some form of "if you don't think an attacker controls your internet connection"; see the previous section for a discussion of why this is problematic.<br />
<br />
==== [https://bitcointalk.org/index.php?topic=128055.0 picocoin] ====<br />
<br />
Simplified Payment Verification is the verification mechanism used in picocoin.<br />
<br />
The library (libccoin) that picocoin is based on includes code for validating scripts and blocks; this could potentially be used to implement a full-chain client.<br />
<br />
==== [[Electrum]] ====<br />
<br />
Electrum fetches blockchain information from Electrum servers, bitcoin nodes that index the blockchain by address.<br />
Electrum performs Simple Payment Verification to check the transactions returned by servers.<br />
For this, it fetches blokchain headers from about 10 random servers.<br />
In addition, Electrum servers are authenticated by SSL, in order to protect users from MITM attacks.<br />
<br />
=== Unused Output Tree in the Block chain (UOT) ===<br />
<br />
There have been several proposals (the first appears to be [https://bitcointalk.org/index.php?topic=21995.0 this one] by gmaxwell, who called it an "open transaction tree", although the term "open" is now taken to mean "not yet mined into the block chain" rather than "unspent") to form a tree of unused transaction outputs at each block in the chain, hash it as a Merkle tree, and encode the root hash in the block chain (probably as part of the coinbase input). This will be called an Unused Output Tree (UOT). The first detailed proposal so far appears to be [https://en.bitcoin.it/wiki/User:DiThi/MTUT Alberto Torres' proposal]; etotheipi's [https://bitcointalk.org/index.php?topic=88208.0 ultimate block chain compression] is a variant of this.<br />
<br />
If such UOT hashes were included in the block chain, a client which shipped with a [https://en.bitcoin.it/wiki/Vocabulary checkpoint] block that had a UOT would only need to download blocks after the checkpoint. Moreover, once the client had downloaded those blocks and confirmed their UOTs, it could discard all but the most recent block containing a UOT.<br />
<br />
Hostile miners may insert blocks into the chain which have what claims to be a UOT, but which is actually invalid. It is unlikely that such blocks could be kept out of the chain because, again, this would require adding a new block validity criterion, and miners implementing this new criterion would risk "mining on the wrong side" of a fork, which could cost them a lot of money. Therefore, any UOT strategy would need to cope with the fact that not every block containing a UOT entry can be trusted.<br />
<br />
Note that at the present moment no standard format for such Unused Output Tree hashes has been agreed upon, nor do any of the blocks in the chain contain them. The [https://bitcointalk.org/index.php?topic=91954 ultraprune] feature added to bitcoind-0.8 maintains a similar data structure on the client's disk. It does not put this data structure or its hash anywhere in the block chain.<br />
<br />
== Server-Trusting Clients ==<br />
<br />
These clients involve a high level of trust in the server they rely upon. Mechanisms for authenticating the server, and for confirming that the server has not been compromised, are usually not explained.<br />
<br />
All thin clients listed below currently connect to a single server, and are vulnerable to an attack similar to a double-spend. The attack can be run by that single server - the server can just lie to them that they received a Bitcoin transaction, and they, assuming the server does not lie, perform some service, transfer funds or send goods without actually receiving any Bitcoin in exchange. Therefore, they are implicitly trusting it.<br />
<br />
Future enhancements have been suggested that will have the client talk to multiple servers and broadcast transactions and query all of them. Unfortunately it is well known to security researchers that this does not actually increase security; it simply makes the exploits more complicated and difficult to find. Security researchers have a name for this phenomenon: it is called a "Sybil attack"<ref>http://en.wikipedia.org/wiki/Sybil_attack</ref>. [https://bitcointalk.org/index.php?topic=88208.msg975201#msg975201 This post] on bitcointalk explains how some governments (notably Iran and China) already perform these sorts of attacks on their own citizens, with the coerced assistance of SSL certificate authorities.<br />
<br />
Clients with a checkpoint (even a very old one) that download and validate the headers for the whole block chain are [http://bitcoinmedia.com/the-irc-bootstrap-method-is-flawed/#comment-4243 not vulnerable] to Sybil attacks in the following sense: they can always ensure that an attack would cost more than the amount being stolen.<br />
<br />
=== [[BCCAPI]] ===<br />
<br />
== Other ==<br />
<br />
* A [http://sourceforge.net/mailarchive/message.php?msg_id=28633866 thread] on bitcoin-dev<br />
* A [http://bitcoin.stackexchange.com/questions/2584/is-reclaiming-disk-space-already-implemented-how-effective-will-it-be/2589 question] on bitcoin.stackexchange.com<br />
* The [[Weaknesses#Sybil_attack|sybil attack (also known as "cancer nodes")]] paragraph explains some of the issues with thin clients that base security on trusting whatever "a majority of the IP addresses I can see" say.<br />
* [http://bitcoin.stackexchange.com/questions/2613/how-secure-are-various-models-of-bitcoin-clients related discussion on Stack Exchange]<br />
* A hypothesized [https://bitcointalk.org/index.php?topic=134318.msg1441171#msg1441171 intermediate security class] between SPV and full-chain validation.<br />
<br />
<references><br />
<br />
[[Category:Technical]]<br />
[[category:Clients]]<br />
[[Category:Security]]</div>Lapp0https://en.bitcoin.it/w/index.php?title=Talk:Paper_Wallet_(Single_Key)&diff=54688Talk:Paper Wallet (Single Key)2015-02-27T19:55:03Z<p>Lapp0: /* Is there a good reason to omit bitcoinpaperwallet.com from this page? */</p>
<hr />
<div>== Running paper wallets off of live websites ==<br />
<br />
Let's never recommend this to users. It is ALWAYS a bad idea to run HTML/JS off of a live website. It does not matter whether you disconnect from the Internet after loading up the HTML -- the code you have loaded may already have been tampered with. At the moment, virtually all HTML/JS based wallet generators allow downloading from github with easy checksumming, so let's always recommend downloading the ZIP file and running entirely offline after verifying signatures.<br />
<br />
[[User:Canton|Canton]] ([[User talk:Canton|talk]]) 22:51, 20 January 2014 (GMT)<br />
<br />
== Self Promotion ==<br />
<br />
As bitcoinpaperwallet.com guy, I admit to it! :) But I also think there should be some good guidelines considering the most recent edits to this page:<br />
<br />
1) When listing services, let's alphabetize them, or put them in chronological order (oldest and most venerable to newest). Bitaddress.org shouldn't get pushed to the end of the list just because pointbiz doesn't actively monitor this page.<br />
<br />
2) When discussing general topics (like entropy) it's inappropriate to link out to a particular websites. The only time you should link to an external website is from the references section, or when the link clearly indicates you're going to be sent to an external website.<br />
<br />
[[User:Canton|Canton]] ([[User talk:Canton|talk]]) 22:51, 20 January 2014 (GMT)<br />
<br />
== Paper wallets a bad idea - why? ==<br />
<br />
Recently the article was changed to add a 'why' tag to the idea that 'storing Bitcoin' on a paper wallet is a generally perceived to be a bad idea. I have to agree with that tag. I actually find the opposite when reading about the best way to store one's private keys. Perhaps it should be expanded instead to a Pros / Cons section? The 'Printer Security' section would then be merged into the Cons section. [[User:TheRealSteve|TheRealSteve]] ([[User talk:TheRealSteve|talk]]) 14:26, 10 February 2015 (UTC)<br />
:I don't know why this is so discouraged either. If anything, I think this page should be shortened and merged into the [[paper wallet]] page under a new section to prevent confusion. New users may not know what an ECDSA private key is, even if they have theirs on paper. [[User:Taras|Taras]] ([[User talk:Taras|talk]]) 14:31, 10 February 2015 (UTC)<br />
::I added that tag, because I think it's poor form (in general) to say: "This is a bad thing to do" and not offer any explanation. People who have the knowlegde to say that, also should be able to explain it.<br />
<br />
::Judging from the history the two were separated to differentiate between HD paper wallets (although I would call those "Paper backups" and Single key "paper wallets". One reason given is that a single key on a paper is not a wallet. I think it's debatable if a HD seed printed on paper makes that paper a wallet. For proper wallet functionality you'll need some way to sign and send a tx, so anything "paper" is not a proper wallet, IMHO. But of course nobody thinks of a wallet that can sign txs etc., if they say "paper wallet" to begin with. <br />
<br />
::I support merging this with paper wallet and also a pro/con section. [[User:Newar|Newar]] ([[User talk:Newar|talk]]) 15:04, 10 February 2015 (UTC)<br />
<br />
:::I support merging and having a pro/con section as well. I think this page should be renamed back to "Paper Wallet". It's fine to have a section on other forms of paper backups (e.g. HD mnemonic paper backups) but I don't like at all how HD mnemonic paper backups are now the default destination for "Paper Wallet" since this will certainly confuse anyone who has read about paper wallets in books, articles, forums, etc.<br />
:::[[User:Canton|Canton]] ([[User talk:Canton|talk]]) 22:05, 26 February 2015 (UTC)Canton<br />
<br />
== Paper wallets vs cold storage ==<br />
<br />
The term 'paper wallets' also seems to be used at times for objects made out of metal, plastic, etc. To avoid that mixup further, should the article instead be renamed 'Cold storage' or even 'Storage methods', listing the various methods (be that an offline computer which doesn't need more than 1 paragraph, or literal paper wallets, physical coins (e.g. Casascius), insert-your-method-here? [[User:TheRealSteve|TheRealSteve]] ([[User talk:TheRealSteve|talk]]) 14:29, 10 February 2015 (UTC)<br />
:I think since "Paper wallet" is such an ubiquitous and well known term, it should have its own page. An overview over different "Cold storage methods" would then link to that page. Or make a category "Cold storage methods" and have a page for each, but most can be summarised in a single paragraph, so I'd lean to the overview solution. [[User:Newar|Newar]] ([[User talk:Newar|talk]]) 15:09, 10 February 2015 (UTC)<br />
<br />
== Why rename Paper Wallets to "Paper ECDSA private keys"? ==<br />
<br />
Why has "Paper Wallet" -- a well understood term in the bitcoin community -- been renamed to "Paper ECDSA private keys"?<br />
<br />
It seems to me that if someone is searching for information about paper wallets, they should get information about those things everyone calls paper wallets.<br />
<br />
While paper wallet may be a misnomer (they're not always made of paper, and they're not wallets in the truest sense) it's the commonly understood term for what you get when you carry around a ECDSA private key on a non-digital artifact (paper, wood, metal, etc.)<br />
<br />
Renaming this page to "Paper ECDSA private keys" would be like going to wikipedia and renaming the entry for "Koala Bear" to "Koala Marsupial" since it's not truly a bear.<br />
<br />
[[User:Canton|Canton]] ([[User talk:Canton|talk]]) 22:01, 26 February 2015 (UTC)Canton<br />
:I fully support reverting back to the term "Paper Wallet". I think the change to "Paper ECDSA private keys" is so ridiculously unsupported that it should be considered vandalism.<br />
:[[User:Chinawat|Chinawat]] ([[User talk:Chinawat|talk]]) 12:40, 27 February 2015 (UTC)<br />
::Reverted Luke-Jr's moves. No consensus for such a change. [[User:Gladoscc|Gladoscc]] ([[User talk:Gladoscc|talk]]) 12:46, 27 February 2015 (UTC)<br />
<br />
== Is there a good reason to omit bitcoinpaperwallet.com from this page? ==<br />
<br />
LukeJr has repeatedly removed the link to [[BitcoinPaperWallet]] with the explanation "BitcoinPaperWallet was removed because it is a website for generating private keys".<br />
<br />
By that logic, every single service for generating paper wallets (e.g. bitaddress.org) should be removed.<br />
<br />
I'm not clear as to what the intent here is, and I'm not eager to get into a revision battle. Can someone explain why BitcoinPaperWallet shouldn't be linked?<br />
<br />
[[User:Canton|Canton]] ([[User talk:Canton|talk]]) 22:12, 26 February 2015 (UTC)Canton<br />
<br />
:It makes sense to remove bitaddress from pages discussing wallets because is not within the scope of the article, just as BitcoinPaperWallet isn't within the scope of this article because this is an article about generating paper wallets.<br />
--[[User:Lapp0|Lapp0]] ([[User talk:Lapp0|talk]])</div>Lapp0https://en.bitcoin.it/w/index.php?title=Talk:Paper_Wallet_(Single_Key)&diff=54687Talk:Paper Wallet (Single Key)2015-02-27T19:54:53Z<p>Lapp0: /* Is there a good reason to omit bitcoinpaperwallet.com from this page? */</p>
<hr />
<div>== Running paper wallets off of live websites ==<br />
<br />
Let's never recommend this to users. It is ALWAYS a bad idea to run HTML/JS off of a live website. It does not matter whether you disconnect from the Internet after loading up the HTML -- the code you have loaded may already have been tampered with. At the moment, virtually all HTML/JS based wallet generators allow downloading from github with easy checksumming, so let's always recommend downloading the ZIP file and running entirely offline after verifying signatures.<br />
<br />
[[User:Canton|Canton]] ([[User talk:Canton|talk]]) 22:51, 20 January 2014 (GMT)<br />
<br />
== Self Promotion ==<br />
<br />
As bitcoinpaperwallet.com guy, I admit to it! :) But I also think there should be some good guidelines considering the most recent edits to this page:<br />
<br />
1) When listing services, let's alphabetize them, or put them in chronological order (oldest and most venerable to newest). Bitaddress.org shouldn't get pushed to the end of the list just because pointbiz doesn't actively monitor this page.<br />
<br />
2) When discussing general topics (like entropy) it's inappropriate to link out to a particular websites. The only time you should link to an external website is from the references section, or when the link clearly indicates you're going to be sent to an external website.<br />
<br />
[[User:Canton|Canton]] ([[User talk:Canton|talk]]) 22:51, 20 January 2014 (GMT)<br />
<br />
== Paper wallets a bad idea - why? ==<br />
<br />
Recently the article was changed to add a 'why' tag to the idea that 'storing Bitcoin' on a paper wallet is a generally perceived to be a bad idea. I have to agree with that tag. I actually find the opposite when reading about the best way to store one's private keys. Perhaps it should be expanded instead to a Pros / Cons section? The 'Printer Security' section would then be merged into the Cons section. [[User:TheRealSteve|TheRealSteve]] ([[User talk:TheRealSteve|talk]]) 14:26, 10 February 2015 (UTC)<br />
:I don't know why this is so discouraged either. If anything, I think this page should be shortened and merged into the [[paper wallet]] page under a new section to prevent confusion. New users may not know what an ECDSA private key is, even if they have theirs on paper. [[User:Taras|Taras]] ([[User talk:Taras|talk]]) 14:31, 10 February 2015 (UTC)<br />
::I added that tag, because I think it's poor form (in general) to say: "This is a bad thing to do" and not offer any explanation. People who have the knowlegde to say that, also should be able to explain it.<br />
<br />
::Judging from the history the two were separated to differentiate between HD paper wallets (although I would call those "Paper backups" and Single key "paper wallets". One reason given is that a single key on a paper is not a wallet. I think it's debatable if a HD seed printed on paper makes that paper a wallet. For proper wallet functionality you'll need some way to sign and send a tx, so anything "paper" is not a proper wallet, IMHO. But of course nobody thinks of a wallet that can sign txs etc., if they say "paper wallet" to begin with. <br />
<br />
::I support merging this with paper wallet and also a pro/con section. [[User:Newar|Newar]] ([[User talk:Newar|talk]]) 15:04, 10 February 2015 (UTC)<br />
<br />
:::I support merging and having a pro/con section as well. I think this page should be renamed back to "Paper Wallet". It's fine to have a section on other forms of paper backups (e.g. HD mnemonic paper backups) but I don't like at all how HD mnemonic paper backups are now the default destination for "Paper Wallet" since this will certainly confuse anyone who has read about paper wallets in books, articles, forums, etc.<br />
:::[[User:Canton|Canton]] ([[User talk:Canton|talk]]) 22:05, 26 February 2015 (UTC)Canton<br />
<br />
== Paper wallets vs cold storage ==<br />
<br />
The term 'paper wallets' also seems to be used at times for objects made out of metal, plastic, etc. To avoid that mixup further, should the article instead be renamed 'Cold storage' or even 'Storage methods', listing the various methods (be that an offline computer which doesn't need more than 1 paragraph, or literal paper wallets, physical coins (e.g. Casascius), insert-your-method-here? [[User:TheRealSteve|TheRealSteve]] ([[User talk:TheRealSteve|talk]]) 14:29, 10 February 2015 (UTC)<br />
:I think since "Paper wallet" is such an ubiquitous and well known term, it should have its own page. An overview over different "Cold storage methods" would then link to that page. Or make a category "Cold storage methods" and have a page for each, but most can be summarised in a single paragraph, so I'd lean to the overview solution. [[User:Newar|Newar]] ([[User talk:Newar|talk]]) 15:09, 10 February 2015 (UTC)<br />
<br />
== Why rename Paper Wallets to "Paper ECDSA private keys"? ==<br />
<br />
Why has "Paper Wallet" -- a well understood term in the bitcoin community -- been renamed to "Paper ECDSA private keys"?<br />
<br />
It seems to me that if someone is searching for information about paper wallets, they should get information about those things everyone calls paper wallets.<br />
<br />
While paper wallet may be a misnomer (they're not always made of paper, and they're not wallets in the truest sense) it's the commonly understood term for what you get when you carry around a ECDSA private key on a non-digital artifact (paper, wood, metal, etc.)<br />
<br />
Renaming this page to "Paper ECDSA private keys" would be like going to wikipedia and renaming the entry for "Koala Bear" to "Koala Marsupial" since it's not truly a bear.<br />
<br />
[[User:Canton|Canton]] ([[User talk:Canton|talk]]) 22:01, 26 February 2015 (UTC)Canton<br />
:I fully support reverting back to the term "Paper Wallet". I think the change to "Paper ECDSA private keys" is so ridiculously unsupported that it should be considered vandalism.<br />
:[[User:Chinawat|Chinawat]] ([[User talk:Chinawat|talk]]) 12:40, 27 February 2015 (UTC)<br />
::Reverted Luke-Jr's moves. No consensus for such a change. [[User:Gladoscc|Gladoscc]] ([[User talk:Gladoscc|talk]]) 12:46, 27 February 2015 (UTC)<br />
<br />
== Is there a good reason to omit bitcoinpaperwallet.com from this page? ==<br />
<br />
LukeJr has repeatedly removed the link to [[BitcoinPaperWallet]] with the explanation "BitcoinPaperWallet was removed because it is a website for generating private keys".<br />
<br />
By that logic, every single service for generating paper wallets (e.g. bitaddress.org) should be removed.<br />
<br />
I'm not clear as to what the intent here is, and I'm not eager to get into a revision battle. Can someone explain why BitcoinPaperWallet shouldn't be linked?<br />
<br />
[[User:Canton|Canton]] ([[User talk:Canton|talk]]) 22:12, 26 February 2015 (UTC)Canton<br />
<br />
:It makes sense to remove bitaddress from pages discussing wallets because is not within the scope of the article, just as BitcoinPaperWallet isn't within the scope of this article because this is an article about generating paper wallets.</div>Lapp0https://en.bitcoin.it/w/index.php?title=Talk:Thin_Client_Security&diff=54658Talk:Thin Client Security2015-02-27T05:31:34Z<p>Lapp0: Undo revision 54657 by Lapp0 (talk)</p>
<hr />
<div>Lapp0, please stop deleting my content, which has been on this wiki page for over three years now. If you think it's suddenly no longer true, discuss here first. In particular, you wrote:<br />
<br />
Transactions don't become more valid with more block preceding it's proof.<br />
<br />
Chains become more trustworthy as they become (difficultywise-)longer. This is the most basic principle of blockchain consensus.<br />
<br />
I have to keep putting that "(difficultywise-)" in there so pedantic people don't pounce on me... a 100,000-block chain all at difficulty=1 is "difficultywise-shorter" than a 100-block chain at current difficulty levels (or a one-block chain for that matter). It's not the number of blocks, but their total difficulty.<br />
<br />
You also wrote:<br />
<br />
The vagueness of what Full-chain is should be elaborated on probably explaining it uses SPV proofs<br />
<br />
No, full-chain clients such as the Satoshi client do not use SPV in any way, shape, or form. A full-chain client is a client that implements the main algorithm outlined in Satoshi's whitepaper.<br />
<br />
[[User:Eldentyrell|Eldentyrell]] ([[User talk:Eldentyrell|talk]]) 03:05, 26 February 2015 (UTC)<br />
<br />
This page looks very confused/wrong in many respects. I'm not sure how it can be fixed easily, since it is unclear what exactly it intends to say.<br />
* Generally "thin clients" do not include pruned full nodes, which have processed every block, but afterward discarded (and no longer store) them.<br />
* Even thin clients generally verify block heights as well as depth.<br />
* Thin clients never (neither for height nor depth) check blocks are valid ("well-formed"?). This is the fundamental difference between full nodes vs thin clients.<br />
* Transaction validity is independent of its inclusion in any blockchain.<br />
--[[User:Luke-jr|Luke-jr]] ([[User talk:Luke-jr|talk]]) 07:58, 26 February 2015 (UTC)<br />
<br />
<br />
Luke, thanks for your thoughts. Regarding your points,<br />
<br />
* Good point, I have partitioned "full-chain" into two separate subtypes (those which do and those which don't retain blocks after validating)<br />
* SPV clients do not verify block height. I can take the existing 345308-block bitcoin blockchain, append a single block that re-spends coins I sent two years ago, and use that 345309-block chain to fool an SPV client. By wasting hashpower whose market value is as most one block reward I can fool an SPV client with it, since it will appear to be the difficultywise-longest chain by one block. I cannot fool the Satoshi client this way even with the hashpower of the entire network at my disposal.<br />
* True. I think you may have hastily misread "transaction validity" as "block validity".<br />
* True. I think you may have hastily misread "transaction validity" as "block validity".<br />
<br />
Thanks again!<br />
<br />
[[User:Eldentyrell|Eldentyrell]] ([[User talk:Eldentyrell|talk]]) 23:14, 26 February 2015 (UTC)<br />
<br />
* Since this article deals with security, I do not think the distinction between pruned vs non-pruned is relevant - both nodes have equal security implications.<br />
* SPV nodes are aware that your invalid 345309th block has a height higher than any other chain, and thus verify the block height before considering that chain "best". They do not, as you mention, validate the contents of any of those blocks, and can be fooled this way, but that is unrelated to the block's height.<br />
* I was referring to the statement that "the validity of a transaction is determined by its height", which is simply not true. A transaction is valid before and even if it is never mined.<br />
--[[User:Luke-jr|Luke-jr]] ([[User talk:Luke-jr|talk]]) 01:42, 27 February 2015 (UTC)<br />
<br />
Full-chain is not well defined and isn't common terminology. If you are saying the Satoshi client is full-chain, then you probably mean full node. "full network node" or "full node" is common terminology and is used in the original Bitcoin whitepaper.<br />
<br />
Your definition of transaction validity isn't common and is even incompatible with the Bitcoin whitepaper.<br />
<br />
You added "A full-chain client trusts the [[Protocol_rules#Blocks well-formed|difficultywise-longest]] block chain it can find." which is only true for SPV clients, so you can see why I would be confused as to what this poorly defined "full-chain" client does.<br />
<br />
I don't think the bitcoin wiki is an appropriate place to redefine terminology.<br />
<br />
Finally, I am not deleting your content, I am deleting the wikis content because it is wrong. Please stop blindly reverting my edits, you removing spelling corrections indicates that you don't care about the accuracy of the wiki as much as maximizing the amount of text written by you on the wiki.<br />
--[[User:Lapp0|Lapp0]] ([[User talk:Lapp0|talk]])<br />
<br />
== Major Restructuring ==<br />
<br />
This page was riddled with incorrect uses of words and the creation of new terminology. This leaves the reader confused or mislead. I have restructured this page and attempted to remove most of the inaccurate parts. It's not that I "think it's suddenly no longer true", I know that it hasn't been true for three years and no one has caught it until now.<br />
<br />
--[[User:Lapp0|Lapp0]] ([[User talk:Lapp0|talk]])</div>Lapp0