Bitcoin Wiki - User contributions [en]

CoinPal

2025-09-12T03:49:24Z

Midnightmagic: the message the link points to says the 14th.

'''CoinPal''' was an exchange that accepted [[PayPal]] for relatively small order sizes and a weekly limit on purchases.

The site was first publicly available on December 31, 2010<ref>[http://www.bitcoin.org/smf/index.php?topic=2555.0 CoinPal beta - Buying bitcoins with PayPal]</ref>. On January 14th, 2011 CoinPal introduced an API that allows merchants and others seeking payment to use the service to accept micro-payments<ref>[http://www.bitcoin.org/smf/index.php?topic=2555.msg38148#msg38148 Re: CoinPal beta - Buying bitcoins with PayPal]</ref>. The operator of the site also operates [[CoinCard]] for [[selling bitcoins]].

On April 30th PayPal froze the exchange operator's PayPal account and the exchange announced that service had ended<ref>[http://www.bitcoin.org/smf/index.php?topic=2555.msg101084#msg101084 CoinPal beta - Buying bitcoins with PayPal]</ref>.

==Weekly Limits==
There was a limit on the number of bitcoins each customer can buy each week. This limit depends on the amount of time that has passed since the customer's first order.

{| class="wikitable"
|-
! Minimum days since customer's first order
! Weekly limit
|-
| 0
| 20
|-
| 3
| 40
|-
| 7
| 60
|-
| 14
| 100
|-
| 45
| 160
|}

Those trading on [[Bitcoin-otc|Bitcoin OTC]] can increase their weekly purchase limits by connecting CoinPal to the [[Bitcoin-otc|OTC web of trust]]<ref>[http://coinpal.ndrix.com/user/gpg Authenticate with a PGP Key]</ref>.

==See Also==

* [[Buying bitcoins]]
* [[Selling bitcoins]]
* [http://www.bitcoinmoney.com/post/5086167006/paypal-freezes-out-coinpal So long, CoinPal, and thanks for all the bitcoins!]

==External Links==

* [http://coinpal.ndrix.com/bw CoinPal.ndrix.com] web site

==References==
<references />

User talk:SeedProtector

2025-08-02T01:29:53Z

Midnightmagic: user suspension pending

Your recent edit has been rejected for multiple reasons, but mostly because it appears to be AI slop absent any verifiable reference to anything that exists in reality. Better luck next time. [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 01:29, 2 August 2025 (UTC)

Bitcoin Wiki:Community portal

2025-07-31T06:57:42Z

Midnightmagic: random clean-up of some garbage links that are either abusive or dead — stopped checking the links because this verification work sucks

== Bitcoin Community Forums on various platforms ==
* [https://bitcointalk.org/ Bitcointalk]
* [https://www.reddit.com/r/Bitcoin/ /r/Bitcoin]
* [https://bitcoin.stackexchange.com/ The Bitcoin StackExchange]
* [https://groups.google.com/group/bitcoin-discussion Bitcoin google group (dead now but still available)]
* [http://hubski.com/tag?id=bitcoin Bitcoin on Hubski (dead now but still available)]

===Regions / Languages===
* [http://bitcoin-austria.at/ Bitcoin Austria]
* [https://coinforum.ca Canada's Bitcoin Community]
* [https://www.bitcoin-italia.org Bitcoin Italia]
* [http://www.bitcoin.org.il Isreali Bitcoin Community Forum]
* [http://bitcoincenterkorea.org Bitcoin Center Korea]
* [http://btcsec.com/ BTCsec.com] Russian Website about Bitcoin
* [https://forum.btcsec.com/ BTCsec.com Bitcoin Community Forum (Russian)]
* [http://rubitcoin.com/ Russian Bitcoin Community Forum]
* [https://www.facebook.com/groups/bitcoinph/ Bitcoin Philippine Community]
* [https://www.facebook.com/groups/btcmx/ Bitcoin México Community]
* [https://www.t.me/Barqnet Bitcoin Arabic Community]

=== Local Communities ===
''For an up-to-date list please see [https://www.reddit.com/r/Bitcoin/wiki/local_communities local communities]
* [https://www.reddit.com/r/ArgenBitcoin Argentina bitcoin community]
* [https://www.reddit.com/r/BitcoinAUS Australia bitcoin community]
* [https://www.reddit.com/r/BitcoinAT Austria bitcoin community]
* [https://www.reddit.com/r/BitcoinBE Belgian bitcoin community]
* [https://www.reddit.com/r/BrasilBitcoin Brazil bitcoin community]
* [https://www.reddit.com/r/BitcoinCA Canada bitcoin community]
* [https://www.reddit.com/r/BitcoinDK Denmark bitcoin community]
* [https://www.reddit.com/r/bitcoinsuomi Finland bitcoin community]
* [https://www.reddit.com/r/BitcoinFrance France bitcoin community]
* [https://www.reddit.com/r/BitcoinDE Germany bitcoin community]
* [https://www.reddit.com/r/BitcoinGhana Ghana bitcoin community]
* [https://www.reddit.com/r/BitcoinGT Guatemala bitcoin community]
* [https://www.reddit.com/r/BitcoinIndia India bitcoin community]
* [https://www.reddit.com/r/BitcoinIran Iran bitcoin community]
* [https://www.reddit.com/r/BitcoinIT Italy bitcoin community]
* [https://www.reddit.com/r/BitcoinJP Japan bitcoin community]
* [https://www.reddit.com/r/bitcoinlaos Laos bitcoin community]
* [https://www.reddit.com/r/BitcoinMalaysia Malaysia bitcoin community]
* [https://www.reddit.com/r/BITCOINMEX Mexico bitcoin community]
* [https://www.reddit.com/r/BitcoinNL The Netherlands bitcoin community]
* [https://www.reddit.com/r/BitcoinNO Norway bitcoin community]
* [https://www.bitcoinpk.org/ Pakistan bitcoin community]
* [https://www.reddit.com/r/BitcoinPL Poland bitcoin community]
* [https://www.reddit.com/r/bitcoinsouthafrica South Africa bitcoin community]
* [https://www.reddit.com/r/bitcoines Spain bitcoin community]
* [https://www.reddit.com/r/BitcoinSWE Sweden bitcoin community]
* [https://www.bitcoinassociation.ch/ Swiss (Switzerland) bitcoin community]
* [https://www.reddit.com/r/btctaiwan Taiwan bitcoin community]
* [https://www.reddit.com/r/BitcoinTR Turkey bitcoin community]
* [https://www.reddit.com/r/BitcoinUK United Kingdom bitcoin community]
** [https://www.reddit.com/r/BitcoinLondon London bitcoin community]
* [https://www.reddit.com/r/BitcoinUSA USA bitcoin community]
** [https://www.reddit.com/r/BitcoinBayArea Bay Area, CA bitcoin community]
** [https://www.reddit.com/r/DenverBitcoin/ Denver, CO bitcoin community]
** [https://www.reddit.com/r/BitcoinAsheville Asheville, NC bitcoin community]
** [https://www.reddit.com/r/BitcoinAlbuquerque Albuquerque, NM bitcoin community]
** [https://www.reddit.com/r/BitcoinNY New York City, NY bitcoin community]
** [https://www.reddit.com/r/BitcoinPA Pennsylvania bitcoin community]
** [https://www.reddit.com/r/BitcoinNashville Nashville, TN bitcoin community]
** [https://reddit.com/r/BitcoinAustin/ Austin, TX bitcoin community]
** [https://www.reddit.com/r/BitcoinSeattle Seattle, WA bitcoin community]
* [https://www.reddit.com/r/BitcoinVzla Venezuela bitcoin community]

== Bitcoin Community Groups on Bitcoin Wiki platform ==

=== Special interests ===
* [[Bitcoin Wiki]]-group

====Clusters====
There are various temporary and permanent clusters where bitcoin-friendly communities form. Temporary clusters are listed in [[Bitcoin Wiki:Community_portal#Events|events]]. Permanent communities include:

* [https://bitcointalk.org/index.php?topic=66832.0 Free State Project] New Hampshire
* [http://www.thebitcointrader.com/2012/05/bitcoins-hogwarts-san-francisco-tech.html 20 Mission] San Francisco, CA

== IRC ==

* See [[IRC_channels|IRC channels]]

==Wiki Users==

* [[Special:ListUsers|List of Users]] registered on the Bitcoin wiki.

== Events ==
Periodic events where Bitcoin community meets include PorcFest, Chaos Computer Camp, Burning Man, Bitcoin conferences and more.

* [[Meetups]]
* [https://bitcointalk.org/index.php?topic=4526.0 Events, conferences and other events]

==Bitcoin Related Publications==

* [https://twitter.com/TopNewsBitcoin/bitcoin TopNewsBitcoin/bitcoin] Twitter list
* See [[:Category:Blogs|Blogs]] category
* See [[:Category:Directories|Directories]] category
* See [[Press]]

==Education==

* [[:Category:Educational|Educational category]]

== Maps ==
* [http://coinmap.org/ CoinMap], map of merchants accepting bitcoin
* [[Bitcoin.local]] Local exchanges
* [[Bitcoin Users Worldwide]] - Find nearby Bitcoin users • Engage in local trade • Add your own offers • Get notifications

== Merchants ==
*[https://hodlhodl.com/ Hodl Hodl] is a P2P cryptocurrency exchange that allows users to trade directly with each other and it doesn't hold user funds
*[https://localbitcoins.com/ LOCALBITCOINS] Buy and sell bitcoins near you, Instant. Secure. Private , Trade bitcoins in 13633 cities and 248 countries

== Monitoring ==
* [https://markets.blockchain.info/ BLOCKCHAIN.INFO] News and market data for the Bitcoin ecosystem.
* [https://bitcoinchain.com/ BitcoinChain.com] provides Bitcoin Block Explorer, Exchange Markets, Mining Pools Data.
* [https://bitcoincharts.com/markets/ Bitcoin Charts] displays an overview of Bitcoin exchange markets.
* [https://hodlwave.com HODL Waves] Bitcoin UTXO Age Distribution Live Chart
* [https://www.cryptocompare.com/coins/btc/overview/USD CryptoCompare.com] Overview, Forum, Live Streaming Markets, Charts and Trades.
* The [http://www.bitcoinmonitor.com/ Bitcoin Monitor] visualizes transactions, new blocks and trades on markets as they are happening.
* [http://www.bitcoinwatch.com/ Bitcoin Watch] has various statistics on things like the size of the economy or the number of transactions.
* [http://bitcoinx.io/ BitcoinX.io] monitors and displays Bitcoin exchanges and Bitcoin wallets with rankings and tools.
* [https://blockchain.info/ BLOCKCHAIN.INFO - NORMAL] Discover the world's most popular Bitcoin wallet. View detailed information and charts on all Bitcoin transactions and blocks. Visit today.

== Bitcoin Project ==
* [https://bitcoin.org/ Bitcoin.org] Bitcoin Community Information for Individuals, Businesses, and Developers
* [https://bitcoincore.org/ Bitcoin Core] Project Site
* [https://github.com/bitcoin/bitcoin Bitcoin Core source code repository]
* [https://gitian.org/ Gitian] for auditing reproducible binaries produced in the [https://gist.github.com/806265 Bitcoin build process]
* [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev bitcoin-dev] and [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-discuss bitcoin-discuss] mailing lists
* [[:Category:Developer|Developer]] pages

== Non-profit Organizations ==

* [[List_of_Bitcoin_non-profits_around_the_world|List of Bitcoin non-profits around the world]]

== External Communities ==
* [https://www.quora.com/topic/Bitcoin Quora] Bitcoin topic Q&A community.

Bitcoin Foundation

2025-07-02T21:58:17Z

Midnightmagic: /* Criticism */ fixing a link to a dead vice.com article, to the archive.org copy. yes, I know the extra markup doesn't work here yet

The '''Bitcoin Foundation''' is an American nonprofit corporation. It was founded in September 2012 with the stated mission to "standardize, protect and promote the use of [[Bitcoin]] cryptographic money for the benefit of users worldwide."<ref>{{cite news|last=Matonis|first=Jon|title=Bitcoin Foundation launches to drive bitcoin's advancement|date=27 September 2012|url=http://www.forbes.com/sites/jonmatonis/2012/09/27/bitcoin-foundation-launches-to-drive-bitcoins-advancement/|work=Forbes}}</ref> The organization was modeled on the [[Wikipedia:Linux Foundation|Linux Foundation]] and is funded mainly through grants made by for-profit companies that depend on the Bitcoin technology.<ref name="Bitcoin Boom">{{cite news |last=Bustillos |first=Maria |title=The bitcoin boom |url=http://www.newyorker.com/online/blogs/elements/2013/04/the-future-of-bitcoin.html |work=The New Yorker |date=2 April 2013 |accessdate=30 December 2013}}</ref> The Foundation and its leadership have been criticized by the media.<ref name="MB1">{{cite web|last=Neal|first=Meghan|title=Bitcoin is Hiring Lobbyists|website=Motherboard.com|url=http://motherboard.vice.com/read/sorry-cypherpunks-bitcoin-is-hiring-political-lobbyists|date=12 May 2014|accessdate=16 May 2014}}</ref>

==History==

The Bitcoin Foundation was announced on September 27, 2012.<ref>{{cite btct|id=113400|title=<nowiki>[ANN]</nowiki> Bitcoin Foundation|date=27 September 2012}}</ref>

According to its founding documents, the Bitcoin Foundation's original members included [[Gavin Andresen]], [[Charlie Shrem]], [[Mark Karpelès]], [[Peter Vessenes]], [[Roger Ver]], and [[Patrick Murck]]. Current board members are divided into one of three categories: Founding Members, Industry Members, and Individual Members. The board is made up of a combination of elected members of the aforementioned categories. [[Gavin Andresen]] is employed by the foundation as "chief scientist."<ref name="Bitcoin Boom" />

===California DFI error===
In June 2013, the [[Wikipedia:California Department of Financial Institutions|California Department of Financial Institutions]] had erroneously considered the Bitcoin Foundation to be a money transmitter and sent them a letter requesting that they "cease and desist from conducting the business of money transmission in this state,"<ref name="wired">{{cite news |url=http://www.wired.com/wiredenterprise/2013/06/california_dfi/ |first=Robert |last=McMillan |date=24 June 2013 |accessdate=31 December 2013 |title=California says the Bitcoin Foundation is a money-transferrer |work=Wired}}</ref> which prompted a detailed response to the regulators.<ref>{{cite news |url=http://www.coindesk.com/bitcoin-foundation-issues-response-to-cease-and-desist-warning/ |title=Bitcoin Foundation issues response to cease and desist warning |date=3 July 2013 |accessdate=31 December 2013 |work=CoinDesk |first=Emily |last=Spaven}}</ref> The California DFI dissolved several days later.<ref>{{Cite web|title=About Us|publisher=California Department of Business Oversight|url=http://www.dbo.ca.gov/About_DBO/default.asp|accessdate=15 March 2014}}</ref>

===United States Senate assessment===
In November 2013, Patrick Murck, general counsel of the Bitcoin Foundation, testified before a United States Senate committee convened to assess digital currencies, at which the reception of Bitcoin by lawmakers was generally positive.<ref>{{cite news |url= http://www.washingtonpost.com/business/economy/for-bitcoin-a-successful-charm-offensive-on-the-hill/2013/11/22/000ed4b0-53b1-11e3-a7f0-b790929232e1_story.html |title= For Bitcoin, a successful charm offensive on the Hill |date= 23 November 2013 |accessdate= 24
November 2013 |first= Timothy |last= Lee |work= Washington Post}}</ref>

===IRS 501(c)(6) Status Auto-Revocation===
As per the IRS tax-exempt database [https://apps.irs.gov/app/eos/ IRS EOS Database], The Bitcoin Foundation, EIN 46-1671796, was auto-revoked as a 501(c)(6) tax-exempt organization as of 2022/05/15 for failing to file their Form 990-series return or notice for a full three years prior. They were filed under the names "THE BITCOIN FOUNDATION INC" or "BITCOIN FOUNDATION INC". This means they were effectively a dead organization from at least 2019.

==Criticism==
The Foundation and its leadership have been criticized by some in the media.<ref>{{cite web|last=Neal|first=Meghan|title=Bitcoin is Hiring Lobbyists|website=Motherboard.com|url=https://web.archive.org/web/20160304003844/http://motherboard.vice.com/read/sorry-cypherpunks-bitcoin-is-hiring-political-lobbyists|date=May 12, 2014|accessdate=May 16, 2014|archive-url=https://web.archive.org/web/20160304003844/http://motherboard.vice.com/read/sorry-cypherpunks-bitcoin-is-hiring-political-lobbyists|archive-date=2016-03-04|url-status=dead}}</ref><ref name="VW1"/> Former vice-chairman [[Charlie Shrem]] pled guilty to aiding and abetting the operation of an unlicensed money-transmitting business related to his role in assisting agents of the online marketplace [[Silk Road]].<ref>Jerving, Sara (September 6, 2014) [http://online.wsj.com/articles/bitcoin-promoter-charles-shrem-pleads-guilty-1409870506 "Bitcoin Promoter Charles Shrem Pleads Guilty"] ''The Wall Street Journal''</ref><ref name="FShrem1">{{cite web|last=Hill|first=Kashmir|title=Winklevosses, Bitcoin Community Shocked By Arrest of BitInstant CEO Charlie Shrem|website=Forbes.com|url=http://www.forbes.com/sites/kashmirhill/2014/01/27/winklevosses-bitcoin-community-shocked-by-arrest-of-bitinstant-ceo-charlie-shrem/|date=January 27, 2014|accessdate=May 16, 2014}}</ref><ref name="VShrem1">{{cite web|last=Jeffires|first=Adrianne|title=Charlie Shrem resigns from the Bitcoin Foundation after arrest|website=The Verge|url=http://www.theverge.com/2014/1/28/5354328/charlie-shrem-resigns-from-the-bitcoin-foundation-after-arrest-bitinstant|date=January 28, 2014|accessdate=May 16, 2014}}</ref> Executive chairman Peter Vessenes' business relationship to former board member [[Mark Karpeles]], the former CEO of collapsed Bitcoin exchange [[Mt. Gox]], has been highlighted as inappropriate.<ref name="VW1">{{cite web|last=Tiku|first=Nitasha|title=Whistleblower Threatens to Expose Corruption at Bitcoin Foundation|website=ValleyWag|url=http://valleywag.gawker.com/whistleblower-threatens-to-expose-corruption-at-bitcoin-1538965958|date=March 7, 2014|accessdate=May 16, 2014}}</ref> The Foundation has also suffered scrutiny and resignations over its hiring of former child star [[Brock Pierce]].<ref name="FReuters1">{{cite web|last=Menn|first=Joseph|title=Bitcoin Foundation hit by resignations over new director|website= Reuters.com|url=http://www.reuters.com/article/2014/05/16/us-bitcoin-foundation-resignations-idUSBREA4F02B20140516|date=May 16, 2014|accessdate=May 16, 2014}}</ref>

In November 2014, the Bitcoin Foundation announced that it would seek to wind down its education, outreach and public policy initiatives as it turns its focus to core development. Three surveys conducted earlier by the Bitcoin Foundation suggest that many community members, both inside and outside of the organization, want to see it adopt a stronger focus on bitcoin’s open-source technology development. <ref>{{cite news | url= http://www.coindesk.com/bitcoin-foundation-shift-core-development/| title= Bitcoin Foundation Pledges to Focus Solely on Core Development| accessdate=19 November 2014 | work= coindesk.com |first= Stan|last= Higgins}}</ref> The Bitcoin community itself is essentially universally negative about the former role of the Foundation as a community or industry representative.<ref name="MB1"/> Some libertarian Bitcoin advocates have criticized the organization's strategy of political lobbying and participation with federal regulators.<ref name="MB1"/> In November of 2014, [[Cody Wilson]] announced his run for board seat in the Bitcoin Foundation, stating "I will run on a platform of the complete dissolution of the Bitcoin Foundation and will begin and end every single one of my public statements with that message." <ref>{{cite news | work=Upstart | last= del Castillo | first= Michael | authorlink=Michael del Castillo | date=22 December 2014 | url=http://upstart.bizjournals.com/entrepreneurs/hot-shots/2014/12/22/it-s-official-cody-wilson-is-trying-to-destroy-the.html?page=all | title=It's official: Cody Wilson is trying to destroy the Bitcoin Foundation from within }}</ref>

Professor and author [[Mark T. Williams]] criticized the Bitcoin Foundation's priorities, writing in a ''[[Business Insider]]'' editorial that "A Foundation of 'B' players has no business claiming it is a protector of a system that remains vulnerable and untrustworthy."<ref>{{cite news | work=Business Insider | last=Williams | first=Mark T. | authorlink=Mark T. Williams | date=25 February 2014 | url=http://www.businessinsider.com/mark-williams-bitcoin-lehman-brothers-type-event-2014-2 | title=Mt Gox: The tower of toxic sludge }}</ref>

==External Links==

* [http://www.BitcoinFoundation.org BitcoinFoundation.org] website

==References==
<references />
{{wp|Bitcoin_Foundation}}

Bitcoin Foundation

2025-07-02T21:46:39Z

Midnightmagic: minor

The '''Bitcoin Foundation''' is an American nonprofit corporation. It was founded in September 2012 with the stated mission to "standardize, protect and promote the use of [[Bitcoin]] cryptographic money for the benefit of users worldwide."<ref>{{cite news|last=Matonis|first=Jon|title=Bitcoin Foundation launches to drive bitcoin's advancement|date=27 September 2012|url=http://www.forbes.com/sites/jonmatonis/2012/09/27/bitcoin-foundation-launches-to-drive-bitcoins-advancement/|work=Forbes}}</ref> The organization was modeled on the [[Wikipedia:Linux Foundation|Linux Foundation]] and is funded mainly through grants made by for-profit companies that depend on the Bitcoin technology.<ref name="Bitcoin Boom">{{cite news |last=Bustillos |first=Maria |title=The bitcoin boom |url=http://www.newyorker.com/online/blogs/elements/2013/04/the-future-of-bitcoin.html |work=The New Yorker |date=2 April 2013 |accessdate=30 December 2013}}</ref> The Foundation and its leadership have been criticized by the media.<ref name="MB1">{{cite web|last=Neal|first=Meghan|title=Bitcoin is Hiring Lobbyists|website=Motherboard.com|url=http://motherboard.vice.com/read/sorry-cypherpunks-bitcoin-is-hiring-political-lobbyists|date=12 May 2014|accessdate=16 May 2014}}</ref>

==History==

The Bitcoin Foundation was announced on September 27, 2012.<ref>{{cite btct|id=113400|title=<nowiki>[ANN]</nowiki> Bitcoin Foundation|date=27 September 2012}}</ref>

According to its founding documents, the Bitcoin Foundation's original members included [[Gavin Andresen]], [[Charlie Shrem]], [[Mark Karpelès]], [[Peter Vessenes]], [[Roger Ver]], and [[Patrick Murck]]. Current board members are divided into one of three categories: Founding Members, Industry Members, and Individual Members. The board is made up of a combination of elected members of the aforementioned categories. [[Gavin Andresen]] is employed by the foundation as "chief scientist."<ref name="Bitcoin Boom" />

===California DFI error===
In June 2013, the [[Wikipedia:California Department of Financial Institutions|California Department of Financial Institutions]] had erroneously considered the Bitcoin Foundation to be a money transmitter and sent them a letter requesting that they "cease and desist from conducting the business of money transmission in this state,"<ref name="wired">{{cite news |url=http://www.wired.com/wiredenterprise/2013/06/california_dfi/ |first=Robert |last=McMillan |date=24 June 2013 |accessdate=31 December 2013 |title=California says the Bitcoin Foundation is a money-transferrer |work=Wired}}</ref> which prompted a detailed response to the regulators.<ref>{{cite news |url=http://www.coindesk.com/bitcoin-foundation-issues-response-to-cease-and-desist-warning/ |title=Bitcoin Foundation issues response to cease and desist warning |date=3 July 2013 |accessdate=31 December 2013 |work=CoinDesk |first=Emily |last=Spaven}}</ref> The California DFI dissolved several days later.<ref>{{Cite web|title=About Us|publisher=California Department of Business Oversight|url=http://www.dbo.ca.gov/About_DBO/default.asp|accessdate=15 March 2014}}</ref>

===United States Senate assessment===
In November 2013, Patrick Murck, general counsel of the Bitcoin Foundation, testified before a United States Senate committee convened to assess digital currencies, at which the reception of Bitcoin by lawmakers was generally positive.<ref>{{cite news |url= http://www.washingtonpost.com/business/economy/for-bitcoin-a-successful-charm-offensive-on-the-hill/2013/11/22/000ed4b0-53b1-11e3-a7f0-b790929232e1_story.html |title= For Bitcoin, a successful charm offensive on the Hill |date= 23 November 2013 |accessdate= 24
November 2013 |first= Timothy |last= Lee |work= Washington Post}}</ref>

===IRS 501(c)(6) Status Auto-Revocation===
As per the IRS tax-exempt database [https://apps.irs.gov/app/eos/ IRS EOS Database], The Bitcoin Foundation, EIN 46-1671796, was auto-revoked as a 501(c)(6) tax-exempt organization as of 2022/05/15 for failing to file their Form 990-series return or notice for a full three years prior. They were filed under the names "THE BITCOIN FOUNDATION INC" or "BITCOIN FOUNDATION INC". This means they were effectively a dead organization from at least 2019.

==Criticism==
The Foundation and its leadership have been criticized by some in the media.<ref name="MB1">{{cite web|last=Neal|first=Meghan|title=Bitcoin is Hiring Lobbyists|website=Motherboard.com|url=http://motherboard.vice.com/read/sorry-cypherpunks-bitcoin-is-hiring-political-lobbyists|date=May 12, 2014|accessdate=May 16, 2014}}</ref><ref name="VW1"/> Former vice-chairman [[Charlie Shrem]] pled guilty to aiding and abetting the operation of an unlicensed money-transmitting business related to his role in assisting agents of the online marketplace [[Silk Road]].<ref>Jerving, Sara (September 6, 2014) [http://online.wsj.com/articles/bitcoin-promoter-charles-shrem-pleads-guilty-1409870506 "Bitcoin Promoter Charles Shrem Pleads Guilty"] ''The Wall Street Journal''</ref><ref name="FShrem1">{{cite web|last=Hill|first=Kashmir|title=Winklevosses, Bitcoin Community Shocked By Arrest of BitInstant CEO Charlie Shrem|website=Forbes.com|url=http://www.forbes.com/sites/kashmirhill/2014/01/27/winklevosses-bitcoin-community-shocked-by-arrest-of-bitinstant-ceo-charlie-shrem/|date=January 27, 2014|accessdate=May 16, 2014}}</ref><ref name="VShrem1">{{cite web|last=Jeffires|first=Adrianne|title=Charlie Shrem resigns from the Bitcoin Foundation after arrest|website=The Verge|url=http://www.theverge.com/2014/1/28/5354328/charlie-shrem-resigns-from-the-bitcoin-foundation-after-arrest-bitinstant|date=January 28, 2014|accessdate=May 16, 2014}}</ref> Executive chairman Peter Vessenes' business relationship to former board member [[Mark Karpeles]], the former CEO of collapsed Bitcoin exchange [[Mt. Gox]], has been highlighted as inappropriate.<ref name="VW1">{{cite web|last=Tiku|first=Nitasha|title=Whistleblower Threatens to Expose Corruption at Bitcoin Foundation|website=ValleyWag|url=http://valleywag.gawker.com/whistleblower-threatens-to-expose-corruption-at-bitcoin-1538965958|date=March 7, 2014|accessdate=May 16, 2014}}</ref> The Foundation has also suffered scrutiny and resignations over its hiring of former child star [[Brock Pierce]].<ref name="FReuters1">{{cite web|last=Menn|first=Joseph|title=Bitcoin Foundation hit by resignations over new director|website= Reuters.com|url=http://www.reuters.com/article/2014/05/16/us-bitcoin-foundation-resignations-idUSBREA4F02B20140516|date=May 16, 2014|accessdate=May 16, 2014}}</ref>

In November 2014, the Bitcoin Foundation announced that it would seek to wind down its education, outreach and public policy initiatives as it turns its focus to core development. Three surveys conducted earlier by the Bitcoin Foundation suggest that many community members, both inside and outside of the organization, want to see it adopt a stronger focus on bitcoin’s open-source technology development. <ref>{{cite news | url= http://www.coindesk.com/bitcoin-foundation-shift-core-development/| title= Bitcoin Foundation Pledges to Focus Solely on Core Development| accessdate=19 November 2014 | work= coindesk.com |first= Stan|last= Higgins}}</ref> The Bitcoin community itself is divided over the role of the Foundation as a community or industry representative.<ref name="MB1"/> Some libertarian Bitcoin advocates have criticized the organization's strategy of political lobbying and participation with federal regulators.<ref name="MB1"/> In November of 2014, [[Cody Wilson]] announced his run for board seat in the Bitcoin Foundation, stating "I will run on a platform of the complete dissolution of the Bitcoin Foundation and will begin and end every single one of my public statements with that message." <ref>{{cite news | work=Upstart | last= del Castillo | first= Michael | authorlink=Michael del Castillo | date=22 December 2014 | url=http://upstart.bizjournals.com/entrepreneurs/hot-shots/2014/12/22/it-s-official-cody-wilson-is-trying-to-destroy-the.html?page=all | title=It's official: Cody Wilson is trying to destroy the Bitcoin Foundation from within }}</ref>

Professor and author [[Mark T. Williams]] criticized the Bitcoin Foundation's priorities, writing in a ''[[Business Insider]]'' editorial that "A Foundation of 'B' players has no business claiming it is a protector of a system that remains vulnerable and untrustworthy."<ref>{{cite news | work=Business Insider | last=Williams | first=Mark T. | authorlink=Mark T. Williams | date=25 February 2014 | url=http://www.businessinsider.com/mark-williams-bitcoin-lehman-brothers-type-event-2014-2 | title=Mt Gox: The tower of toxic sludge }}</ref>

==External Links==

* [http://www.BitcoinFoundation.org BitcoinFoundation.org] website

==References==
<references />
{{wp|Bitcoin_Foundation}}

Bitcoin Foundation

2025-07-02T21:46:17Z

Midnightmagic: /* History */

The '''Bitcoin Foundation''' is an American nonprofit corporation. It was founded in September 2012 with the stated mission to "standardize, protect and promote the use of [[Bitcoin]] cryptographic money for the benefit of users worldwide."<ref>{{cite news|last=Matonis|first=Jon|title=Bitcoin Foundation launches to drive bitcoin's advancement|date=27 September 2012|url=http://www.forbes.com/sites/jonmatonis/2012/09/27/bitcoin-foundation-launches-to-drive-bitcoins-advancement/|work=Forbes}}</ref> The organization was modeled on the [[Wikipedia:Linux Foundation|Linux Foundation]] and is funded mainly through grants made by for-profit companies that depend on the Bitcoin technology.<ref name="Bitcoin Boom">{{cite news |last=Bustillos |first=Maria |title=The bitcoin boom |url=http://www.newyorker.com/online/blogs/elements/2013/04/the-future-of-bitcoin.html |work=The New Yorker |date=2 April 2013 |accessdate=30 December 2013}}</ref> The Foundation and its leadership have been criticized by the media.<ref name="MB1">{{cite web|last=Neal|first=Meghan|title=Bitcoin is Hiring Lobbyists|website=Motherboard.com|url=http://motherboard.vice.com/read/sorry-cypherpunks-bitcoin-is-hiring-political-lobbyists|date=12 May 2014|accessdate=16 May 2014}}</ref>

==History==

The Bitcoin Foundation was announced on September 27, 2012.<ref>{{cite btct|id=113400|title=<nowiki>[ANN]</nowiki> Bitcoin Foundation|date=27 September 2012}}</ref>

According to its founding documents, the Bitcoin Foundation's original members included [[Gavin Andresen]], [[Charlie Shrem]], [[Mark Karpelès]], [[Peter Vessenes]], [[Roger Ver]], and [[Patrick Murck]]. Current board members are divided into one of three categories: Founding Members, Industry Members, and Individual Members. The board is made up of a combination of elected members of the aforementioned categories. [[Gavin Andresen]] is employed by the foundation as "chief scientist."<ref name="Bitcoin Boom" />

===California DFI error===
In June 2013, the [[Wikipedia:California Department of Financial Institutions|California Department of Financial Institutions]] had erroneously considered the Bitcoin Foundation to be a money transmitter and sent them a letter requesting that they "cease and desist from conducting the business of money transmission in this state,"<ref name="wired">{{cite news |url=http://www.wired.com/wiredenterprise/2013/06/california_dfi/ |first=Robert |last=McMillan |date=24 June 2013 |accessdate=31 December 2013 |title=California says the Bitcoin Foundation is a money-transferrer |work=Wired}}</ref> which prompted a detailed response to the regulators.<ref>{{cite news |url=http://www.coindesk.com/bitcoin-foundation-issues-response-to-cease-and-desist-warning/ |title=Bitcoin Foundation issues response to cease and desist warning |date=3 July 2013 |accessdate=31 December 2013 |work=CoinDesk |first=Emily |last=Spaven}}</ref> The California DFI dissolved several days later.<ref>{{Cite web|title=About Us|publisher=California Department of Business Oversight|url=http://www.dbo.ca.gov/About_DBO/default.asp|accessdate=15 March 2014}}</ref>

===United States Senate assessment===
In November 2013, Patrick Murck, general counsel of the Bitcoin Foundation, testified before a United States Senate committee convened to assess digital currencies, at which the reception of Bitcoin by lawmakers was generally positive.<ref>{{cite news |url= http://www.washingtonpost.com/business/economy/for-bitcoin-a-successful-charm-offensive-on-the-hill/2013/11/22/000ed4b0-53b1-11e3-a7f0-b790929232e1_story.html |title= For Bitcoin, a successful charm offensive on the Hill |date= 23 November 2013 |accessdate= 24
November 2013 |first= Timothy |last= Lee |work= Washington Post}}</ref>

===IRS 501(c)3 Status Auto-Revocation===
As per the IRS tax-exempt database [https://apps.irs.gov/app/eos/ IRS EOS Database], The Bitcoin Foundation, EIN 46-1671796, was auto-revoked as a 501(c)(6) tax-exempt organization as of 2022/05/15 for failing to file their Form 990-series return or notice for a full three years prior. They were filed under the names "THE BITCOIN FOUNDATION INC" or "BITCOIN FOUNDATION INC". This means they were effectively a dead organization from at least 2019.

==Criticism==
The Foundation and its leadership have been criticized by some in the media.<ref name="MB1">{{cite web|last=Neal|first=Meghan|title=Bitcoin is Hiring Lobbyists|website=Motherboard.com|url=http://motherboard.vice.com/read/sorry-cypherpunks-bitcoin-is-hiring-political-lobbyists|date=May 12, 2014|accessdate=May 16, 2014}}</ref><ref name="VW1"/> Former vice-chairman [[Charlie Shrem]] pled guilty to aiding and abetting the operation of an unlicensed money-transmitting business related to his role in assisting agents of the online marketplace [[Silk Road]].<ref>Jerving, Sara (September 6, 2014) [http://online.wsj.com/articles/bitcoin-promoter-charles-shrem-pleads-guilty-1409870506 "Bitcoin Promoter Charles Shrem Pleads Guilty"] ''The Wall Street Journal''</ref><ref name="FShrem1">{{cite web|last=Hill|first=Kashmir|title=Winklevosses, Bitcoin Community Shocked By Arrest of BitInstant CEO Charlie Shrem|website=Forbes.com|url=http://www.forbes.com/sites/kashmirhill/2014/01/27/winklevosses-bitcoin-community-shocked-by-arrest-of-bitinstant-ceo-charlie-shrem/|date=January 27, 2014|accessdate=May 16, 2014}}</ref><ref name="VShrem1">{{cite web|last=Jeffires|first=Adrianne|title=Charlie Shrem resigns from the Bitcoin Foundation after arrest|website=The Verge|url=http://www.theverge.com/2014/1/28/5354328/charlie-shrem-resigns-from-the-bitcoin-foundation-after-arrest-bitinstant|date=January 28, 2014|accessdate=May 16, 2014}}</ref> Executive chairman Peter Vessenes' business relationship to former board member [[Mark Karpeles]], the former CEO of collapsed Bitcoin exchange [[Mt. Gox]], has been highlighted as inappropriate.<ref name="VW1">{{cite web|last=Tiku|first=Nitasha|title=Whistleblower Threatens to Expose Corruption at Bitcoin Foundation|website=ValleyWag|url=http://valleywag.gawker.com/whistleblower-threatens-to-expose-corruption-at-bitcoin-1538965958|date=March 7, 2014|accessdate=May 16, 2014}}</ref> The Foundation has also suffered scrutiny and resignations over its hiring of former child star [[Brock Pierce]].<ref name="FReuters1">{{cite web|last=Menn|first=Joseph|title=Bitcoin Foundation hit by resignations over new director|website= Reuters.com|url=http://www.reuters.com/article/2014/05/16/us-bitcoin-foundation-resignations-idUSBREA4F02B20140516|date=May 16, 2014|accessdate=May 16, 2014}}</ref>

In November 2014, the Bitcoin Foundation announced that it would seek to wind down its education, outreach and public policy initiatives as it turns its focus to core development. Three surveys conducted earlier by the Bitcoin Foundation suggest that many community members, both inside and outside of the organization, want to see it adopt a stronger focus on bitcoin’s open-source technology development. <ref>{{cite news | url= http://www.coindesk.com/bitcoin-foundation-shift-core-development/| title= Bitcoin Foundation Pledges to Focus Solely on Core Development| accessdate=19 November 2014 | work= coindesk.com |first= Stan|last= Higgins}}</ref> The Bitcoin community itself is divided over the role of the Foundation as a community or industry representative.<ref name="MB1"/> Some libertarian Bitcoin advocates have criticized the organization's strategy of political lobbying and participation with federal regulators.<ref name="MB1"/> In November of 2014, [[Cody Wilson]] announced his run for board seat in the Bitcoin Foundation, stating "I will run on a platform of the complete dissolution of the Bitcoin Foundation and will begin and end every single one of my public statements with that message." <ref>{{cite news | work=Upstart | last= del Castillo | first= Michael | authorlink=Michael del Castillo | date=22 December 2014 | url=http://upstart.bizjournals.com/entrepreneurs/hot-shots/2014/12/22/it-s-official-cody-wilson-is-trying-to-destroy-the.html?page=all | title=It's official: Cody Wilson is trying to destroy the Bitcoin Foundation from within }}</ref>

Professor and author [[Mark T. Williams]] criticized the Bitcoin Foundation's priorities, writing in a ''[[Business Insider]]'' editorial that "A Foundation of 'B' players has no business claiming it is a protector of a system that remains vulnerable and untrustworthy."<ref>{{cite news | work=Business Insider | last=Williams | first=Mark T. | authorlink=Mark T. Williams | date=25 February 2014 | url=http://www.businessinsider.com/mark-williams-bitcoin-lehman-brothers-type-event-2014-2 | title=Mt Gox: The tower of toxic sludge }}</ref>

==External Links==

* [http://www.BitcoinFoundation.org BitcoinFoundation.org] website

==References==
<references />
{{wp|Bitcoin_Foundation}}

Split-key vanity address

2024-03-11T20:13:46Z

Midnightmagic: sigh

A split-key vanity address is a type of [[vanity address]] generated from one or more ECDSA private keys. The general use case is when a user generates a key-pair and only shares his public key. Everybody can use this public key to find the complementary public key leading to a vanity address. The user can than merge his private key with the complementary private key, leading to the private key of the vanity address. The security of such solution is guaranteed by the properties of the Elliptic Curve Cryptography [http://bitcoin.stackexchange.com/q/3853/323].

== Address generation ==
A split-key vanity address is generated by a specialized software, called a generator. One such sample generator is available as a part of the [[Vanitygen]] program suite. Bitaddress can be used for this purpose as well as explained in this [https://youtu.be/ysccKgSi2RU video]

== Address merging ==
In order to create a usable vanity address, one needs to merge two or more private keys. This can be done with specialized software, such as the [[GoBit Testing Suite]][http://gobittest.appspot.com/]. Another option is using the Vanity Wallet tool of [https://bitaddress.org Bitaddress], but bitaddress only supports legacy addresses, whereas the keymerging tool of [https://vanity-address.bitcoin-uni.de/en/keymerging Bitcoin-Uni] supports P2SH & Bech32 native Segwit as well. An offline keymerging tool called VanityAddressMerger is available from Github [https://github.com/sashmaaan/VanityAddressMerger VanityAddressMerger], this tool supports all mainnet address types. It is recommended to use these tools offline in an incognito browser, while merging partial keys, to get the final private key secure.

== Address generation outsourcing ==
Generating a split-key vanity address can be outsourced to a third party miner without risking your final private key being compromised. Moreover, work on such address generation can be distributed to many miners simultaneously through a use of a pooling service. One example of such a service is [[Vanity Pool]][https://vanitypool.appspot.com/].

Other options for outsourcing vanity address generation include [https://vanity-address.bitcoin-uni.de/en Bitcoin-Uni], [https://vanity.coin.dance Coin Dance Vanity] and [https://vante.me Vante]. These services generate keys on an on-demand basis.

== Address generation fees ==
For outsourcing the finding of vanity addresses, users got to pay fees for the Hardware and ernergy consumtion. The pricing of the services are verry different. Some of them do not update the Bitcoin prices.

== See also ==
* [[Vanitygen]] - a software suite offering an Open-CL split-key vanity address generator
* [https://bitcointalk.org/index.php?topic=81865.msg901491#msg901491 Reddit post] - Discussion on split-key address generation

[[Category:Vanity address]]
[[Category:Software]]
[[Category:Mining - Other]]

{{Stub}}

Vanitygen

2024-03-11T20:11:02Z

Midnightmagic: provisionally deleting references to e.g. vanity pool

'''Warning''': Refrain from utilizing Vanitygen on live websites. Using Vanitygen on websites is not recommended, as there is a high likelihood that these '''platforms might store the generated address's key''', putting your results and coins at risk of being stolen. For a more secure approach, consider employing Vanitysearch by Jean Luc Pons, an open-source and trusted alternative available on GitHub.

'''Vanitygen''' was the first command-line vanity Bitcoin address generator. A few other vanity address generators exist including '''Vanitygen-plus''' and '''VanitySearch'''.

If you're tired of the random addresses generated by regular Bitcoin clients, you can use a vanity address program to create a more personalized address. For example, you could create an address that starts '1Satoshi' and ask people to send Bitcoin to 1SatoshiHHqnDPRSfiZ5GXJ8Gk9dbjO.

Vanity address programs accept as input a pattern (e.g. 1Bitcoin) and create a public address and private key. The amount of time required to find a given pattern depends on how complex the pattern is, the speed of the computer, whether it is using CPU or GPU, and if you get lucky.

The example below (from 2014) illustrates a session of vanitygen. It takes about 10 seconds to create the new public and private keys using a Core 2 Duo E6600 CPU on x86-64 Linux.

Please note that vanitygen is a legacy program and that the information below is provided for historical purposes.

<syntaxhighlight lang="bash">
$ ./vanitygen 1Boat
Difficulty: 4476342
Pattern: 1Boat
Address: 1BoatSLRHtKNngkdXEeobR76b53LETtpyT
Privkey: 5J4XJRyLVgzbXEgh8VNi4qovLzxRftzMd8a18KkdXv4EqAwX3tS
</syntaxhighlight>

Vanitygen includes components to perform address searching on a CPU (vanitygen) and OpenCL-compatible GPU (oclvanitygen). Both can be built from source and are included in the Windows binary package. Also included is oclvanityminer, the vanity address mining client.

Current version: 0.22.

Windows x86+x64 binaries [https://github.com/downloads/samr7/vanitygen/vanitygen-0.20-win.zip here]. PGP signature [http://insight.gotdns.org/~samr7/vanitygen-0.20-win.zip.asc here].

Get the source from [https://github.com/samr7/vanitygen GitHub]. Includes Makefiles for Linux and Mac OS X.

Main discussion at [https://bitcointalk.org/index.php?topic=25804.0 BitcoinTalk].

The latest source doesn't work properly for high-end AMD cards (7XXX and greater). The solution is to change line 459 in oclengine.c from: return quirks; to: return quirks & ~VG_OCL_AMD_BFI_INT;

Windows x86+x64 binaries that solve this problem plus provide support for compressed keys [https://lifeboat.com/oclvanitygen here]. PGP signature [https://lifeboat.com/oclvanitygen.zip.sig here]. If you have any problems with the binaries, join the relevant [https://bitcointalk.org/index.php?topic=301068.0 BitcoinTalk discussion].

== Expected keysearch rate ==
The table below shows the key search rate one can expect from different hardware. The last five examples, which use GPU processors, were taken from [https://bitcointalk.org/index.php?topic=5112311.msg50823897#msg50823897 DaveF's list of speeds] that can be achieved with the [https://github.com/JeanLucPons/VanitySearch VanitySearch] address generator.

'''Keysearch Rates'''
{| class="wikitable sortable"
|-
! CPU !! GPU !! keys/s !! Comment
|-
| Core i5 750 @2.67 GHz || nVidia GTS 250 || 1.54 Mkey/s || 110% CPU [https://bitcointalk.org/index.php?topic=25804.msg378820#msg378820]
|-
| Core2 Duo 6600 || nVidia GTX 285 || 3.5 Mkey/s || 100% CPU / 90% GPU [https://bitcointalk.org/index.php?topic=25804.msg378114#msg378114]
|-
| Sempron 140 || AMD 5830 || 5.5 Mkey/s || 100% CPU / 60% GPU [https://bitcointalk.org/index.php?topic=25804.msg378114#msg378114]
|-
| || AMD Radeon r7 240 || 4 Mkey/s || [https://bitcointalk.org/index.php?topic=25804.msg11872747#msg11872747]
|-
| Core i7 || AMD 6500M || 4.5 Mkey/s || 98% GPU
|-
| || nVidia GeForce GTX 680M || 14-16 Mkey/s || [https://bitcointalk.org/index.php?topic=25804.msg11882134#msg11882134]
|-
| || nVidia GeForce GTX 970 || 38 Mkey/s || [https://bitcointalk.org/index.php?topic=25804.msg11851273#msg11851273]
|-
| Core i7-4702MQ 2.2GHz || || 1.09 Mkey/s ||
|-
| Core i7-4702MQ 2.2GHz || GeForce GT750M || 5.38 Mkey/s ||
|-
| || AMD Radeon r9 280x || 25-35 Mkey/s ||
|-
| || Sapphire Radeon HD 7970 || 28Mkey/s || [https://bitcointalk.org/index.php?topic=25804.msg12269936#msg12269936]
|-
| || AMD Radeon HD 5870 || 30 Mkey/s || [https://bitcointalk.org/index.php?topic=25804.msg12262017#msg12262017]
|-
| || Asus Strix GTX 970 || 40Mkey/s || [https://bitcointalk.org/index.php?topic=25804.msg12269936#msg12269936]
|-
| || nVidia GeForce GTX 780 Ti (3GB 384-bit GDDR5) || 50-60 Mkey/s || [https://bitcointalk.org/index.php?topic=25804.msg11944467#msg11944467]
|-
| Core i5-2500K @ 3.30GHz || AMD RX 480 || 57-64 Mkey/s || With AMD patch [https://nastyfans.org/download/oclvanitygen.txt]
|-
| || GeForce GTX 1060 3GB (9x128 cores) Grid(72x128) || 322 Mkey/s || [https://bitcointalk.org/index.php?topic=5112311.msg50823897#msg50823897]
|-
| || GeForce GTX 1080 Ti (28x128 cores) Grid(224x128) || 896 Mkey/s || [https://bitcointalk.org/index.php?topic=5112311.msg50823897#msg50823897]
|-
| || EVGA RTX 2080 XC ULTRA || 1425 Mkey/s || [https://bitcointalk.org/index.php?topic=5112311.msg50823897#msg50823897]
|-
| || GPU #0 Tesla V100-SXM2-16GB (80x64 cores) Grid(640x128) || 1815 Mkey/s || [https://bitcointalk.org/index.php?topic=5112311.msg50823897#msg50823897]
|-
| || GPU #0 GeForce RTX 2080 SUPER (48x64 cores) Grid(384x256) || 2002 Mkey/s || [https://bitcointalk.org/index.php?topic=5112311.msg50823897#msg50823897]
|}

== Difficulty of finding a vanity address ==
The difficult of discovering a Bitcoin vanity address depends on its exact structure (what are the leading letters or numbers) and how likely such an output is given the algorithms involved, which can consist of several pivots where the difficulty suddenly changes.
{| class="wikitable"
|-
! vanity !! difficulty !! Comment
|-
| 1AAAAA || 259,627,881 ||
|-
| 1QLbz6 || 259,627,881 || This vanity is alphabetically located before a major pivot, the [[RIPEMD160]] hash value of 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF (address: 1QLbz7JHiBTspS962RLKV8GndWFwi5j6Qr).
|-
| 1QLbz7JHiBTspS962RLKV8GndWE || 2.9597E+45 ||
|-
| 1QLbz7 || 837,596,142 || This vanity is partially after a pivot and thus the difficulty increases.
|-
| 1QLbz7JHiBTspS962RLKV8GndWG || 1.6489E+47 || After a major pivot and 59 times as difficult as the 'E' vanity.
|-
| 1QLbz8 || 837,596,142 ||
|-
| 1aaaaa || 15,318,045,009 || After various pivots and subsequently more difficult.
|-
| 1zzzzz || 15,318,045,009 ||
|-
| 1abcdef || 888,446,610,539 || Six characters case sensitive starting with a lower case character.
|-
| 111111 || 1,099,511,627,776 || A special case: leading number 1 (one) is especially difficult.
|-
| 1abcdefg || 51,529,903,411,245 || Seven characters case sensitive starting with a lower case character.
|-
| 1abcdefgh || 2,988,734,397,852,220 || Eight characters case sensitive starting with a lower case character.
|}

== Using a vanity address generator to try to attack addresses ==
You might think that you would be able to find the private key for a given address by running a vanity address generator. In practice, this is considered impossible. Given that the difficulty increases exponentially the longer your vanity is, so does the average time required to find that vanity. The table below shows how an increasingly complex vanity affects the difficulty and average time required to find a match only for that vanity, let alone the full address, for a machine capable of looking through one million keys per second.

Note that many GPU implementations currently (March 2020) allow up to 1,000 Mkeys/s (or more). For example [https://vanitygen.net/ VanityGen] uses [https://github.com/JeanLucPons/VanitySearch VanitySearch] to search more than 7,000 Mkeys/s.

{| class="wikitable"
|-
! vanity !! difficulty !! average time
|-
| 1B || 22 || < 1s
|-
| 1Bi || 1,330 || < 1s
|-
| 1Bit || 77,178 || < 1s
|-
| 1Bitc || 4,476,342 (4.48E+6)|| < 10s
|-
| 1Bitco || 259,627,881 (2.6E+8)|| 3 minutes
|-
| 1Bitcoi || 15,058,417,127 (1.506E+10) || 3 hours
|-
| 1Bitcoin || 8.7339E+11 || 1 week
|-
| 1BitcoinE || 5.0657E+13 || 1 year
|-
| 1BitcoinEa || 2.9381E+15 || 60 years
|-
| 1BitcoinEat || 1.7041E+17 || 3,500 years
|-
| 1BitcoinEate || 9.8837E+18 || 200,000 years
|-
| 1BitcoinEater || 5.7325E+20 || 11,700,000 years
|-
| 1BitcoinEaterAddressDontSend || 1.6209E+47 || 3.3E+33 or 3.3 decillion years.
|}

== Outsourcing vanity address generation ==
The standard way to generate a vanity address is to calculate it yourself by downloading the program and then running it on your system. However, for longer prefixes, you are unlikely to have enough computational resources or time to calculate them. In these cases, you can outsource your vanity address generation to a [[Bitcoin Vanity Generation Website]]. A good idea is to use [https://vanitygen.net/ bitcoin address generation].

== See also ==
* [[Bitcoin Vanity Generation Website]]

[[Category:Vanity address]]

User:ThePiachu

2024-03-11T20:08:36Z

Midnightmagic:

==WARNING: A PAGE ORIGINALLY CREATED BY THIS USER HAS GONE ROGUE AND IS REPORTEDLY STEALING WALLETS==
https://old.reddit.com/r/BitcoinDE/comments/1b9ubhi/bitte_um_eure_einsch%C3%A4tzung/

==Who am I?==
Piotr "ThePiachu" Piasecki

* Bitcoin enthusiast
* Lifetime member of the Bitcoin Foundation
* Master of Science in the field of Computer Science
* Double Bachelor of Science in the fields of Computer Science and Informatics
* Electronics Technician

==My projects==
* http://tpbitcalc.appspot.com/
* https://vanitypool.appspot.com/

== See also ==
*[[Research]]
*[[Vanity Pool]]
*[[GoBit]]
*[[GoBit Testing Suite]]

==My profiles==
* tiny.cc/ThePiachu

Test Cases

2024-03-11T19:56:24Z

Midnightmagic: user's website was reported to be stealing wallet keys

Below are listed test cases to be used for checking compliance with the [[Protocol_specification|Bitcoin Protocol]].

Variables listed in quotation marks are string literals, encoded using the ASCII standard. Variables listed without the quotation marks are numbers or hex dumps.

==Hashes==
===SHA-256===
{| class="wikitable"
|-
! Original !! First hashing !! Second hashing
|-
| "hello" || 0x2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 || 0x9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50
|}

===RIPEMD-160===
{| class="wikitable"
|-
! Original !! SHA hashing !! RIPEMD hashing
|-
| "hello" || 0x2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 || 0xb6a9c8c230722b7c748331a8b450f05566dc7d0f
|}

==Merkle Trees==
==Variable length integer==
==Variable length string==

{{Stub}}

Wallet import format

2024-03-11T19:54:13Z

Midnightmagic: scummy WIF converter was just stealing private keys and was written badly anyway

{{sample}}
A '''wallet import format''' ('''WIF''', also known as a '''wallet export format''') is a way of encoding a private ECDSA key so as to make it easier to copy.

==Private key to WIF==
1. Take a private key.
0C28FCA386C7A227600B2FE50B7CAE{{taggant private key}}11EC86D3BF1FBE471BE89827E19D72AA1D
2. Add a <code>0x80</code> byte in front of it for mainnet addresses or <code>0xef</code> for testnet addresses. Also add a <code>0x01</code> byte at the end if the private key will correspond to a compressed public key.
800C28FCA386C7A227600B2FE50B7C{{taggant private key}}AE11EC86D3BF1FBE471BE89827E19D72AA1D
3. Perform SHA-256 hash on the extended key.
8147786C4D15106333BF278D71DADAF1079EF2D2440A4DDE37D747DED5403592
4. Perform SHA-256 hash on result of SHA-256 hash.
507A5B8DFED0FC6FE8801743720CEDEC06AA5C6FCA72B07C49964492FB98A714
5. Take the first 4 bytes of the second SHA-256 hash; this is the checksum.
507A5B8D
6. Add the 4 checksum bytes from point 5 at the end of the extended key from point 2.
800C28FCA386C7A227600B2FE50B7CAE11EC8{{taggant private key}}6D3BF1FBE471BE89827E19D72AA1D507A5B8D
7. Convert the result from a byte string into a base58 string using [[Base58Check encoding]]. This is the wallet import format (WIF).
5HueCGU8rMjxEXxiPuD5BDk{{taggant private key}}u4MkFqeZyd4dZ1jvhTVqvbTLvyTJ

==WIF to private key==
1. Take a wallet import format (WIF) string.
5HueCGU8rMjxEXxiPuD5BDk{{taggant private key}}u4MkFqeZyd4dZ1jvhTVqvbTLvyTJ
2. Convert it to a byte string using [[Base58Check encoding]].
800C28FCA386C7A227600B2FE50B7CAE11EC{{taggant private key}}86D3BF1FBE471BE89827E19D72AA1D507A5B8D
3. Drop the last 4 checksum bytes from the byte string.
800C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D
4. Drop the first byte (it should be <code>0x80</code>, however legacy Electrum<ref name="electrum-300-wif">[https://github.com/spesmilo/electrum/blob/3.0.0/RELEASE-NOTES#L42]</ref><ref name="electrum-310-wif">[https://github.com/spesmilo/electrum/blob/3.1.0/RELEASE-NOTES#L58]</ref> or some SegWit vanity address generators<ref name="segvan-wif">[https://github.com/nym-zone/segvan/blob/388b157c68c3b45f7c3200cc62a2fea6ffcb5555/segvan.c#L88]</ref> may use <code>0x81-0x87</code>). If the private key corresponded to a compressed public key, also drop the last byte (it should be <code>0x01</code>). If it corresponded to a compressed public key, the WIF string will have started with K or L (or M, if it's exported from legacy Electrum<ref name="electrum-300-wif" /><ref name="electrum-310-wif" /> etc<ref name="segvan-wif" />) instead of 5 (or c instead of 9 on testnet). This is the private key.
0C28FCA386C7A227600B2FE50B7CAE1{{taggant private key}}1EC86D3BF1FBE471BE89827E19D72AA1D

==WIF checksum checking==
1. Take the wallet import format (WIF) string.
5HueCGU8rMjxEXxiPuD5BD{{taggant private key}}ku4MkFqeZyd4dZ1jvhTVqvbTLvyTJ
2. Convert it to a byte string using [[Base58Check encoding]].
800C28FCA386C7A227600B2FE50B7CAE11E{{taggant private key}}C86D3BF1FBE471BE89827E19D72AA1D507A5B8D
3. Drop the last 4 checksum bytes from the byte string.
800C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D
4. Perform SHA-256 hash on the shortened string.
8147786C4D15106333BF278D71DADAF1079EF2D2440A4DDE37D747DED5403592
5. Perform SHA-256 hash on result of SHA-256 hash.
507A5B8DFED0FC6FE8801743720CEDEC06AA5C6FCA72B07C49964492FB98A714
6. Take the first 4 bytes of the second SHA-256 hash; this is the checksum.
507A5B8D
7. Make sure it is the same as the last 4 bytes from point 2.
507A5B8D
8. If they are, and the byte string from point 2 starts with <code>0x80</code> (<code>0xef</code> for testnet addresses), then there is no error.

== References ==
<references />

{{Stub}}
{{Bitcoin Core documentation}}

User:ThePiachu

2024-03-11T19:40:51Z

Midnightmagic: Protected "User:ThePiachu": user banned for a page that steals wallet keys ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite))

==WARNING: A PAGE ORIGINALLY CREATED BY THIS USER HAS GONE ROGUE AND IS STEALING WALLETS==
https://old.reddit.com/r/BitcoinDE/comments/1b9ubhi/bitte_um_eure_einsch%C3%A4tzung/

==Who am I?==
Piotr "ThePiachu" Piasecki

* Bitcoin enthusiast
* Lifetime member of the Bitcoin Foundation
* Master of Science in the field of Computer Science
* Double Bachelor of Science in the fields of Computer Science and Informatics
* Electronics Technician

==My projects==
* http://tpbitcalc.appspot.com/
* https://vanitypool.appspot.com/

== See also ==
*[[Research]]
*[[Vanity Pool]]
*[[GoBit]]
*[[GoBit Testing Suite]]

==My profiles==
* tiny.cc/ThePiachu

User:ThePiachu

2024-03-11T19:39:36Z

Midnightmagic: Super disappointed in you, ThePiachu

Forums

2023-11-20T23:13:38Z

Midnightmagic: removing old template

== General Bitcoin Discussion ==
* [https://bitcointalk.org/ The Bitcoin Forum]. (This is the original Bitcoin Forum, previously [https://web.archive.org/web/20091215005450/http://www.bitcoin.org:80/smf/ on bitcoin.org], where [https://bitcointalk.org/index.php?action=profile;u=3 Satoshi Nakamoto] used to [https://bitcointalk.org/index.php?action=profile;u=3;sa=showPosts post].)
* Reddit:
** [https://www.reddit.com/r/Bitcoin/ /r/Bitcoin]
** [https://www.reddit.com/r/bitcoinbeginners /r/bitcoinbeginners]
** ([https://www.reddit.com/r/Bitcoin/wiki/communities More Bitcoin subreddits])
* [https://www.tradingview.com/chat/#bitcoin TradingView Bitcoin Chat]

== Language/Region Specific ==
* [https://bitcointalk.org/#5 Local Forums], including at this time:
** [https://bitcointalk.org/index.php?board=241.0 العربية (Arabic)]
** [https://bitcointalk.org/index.php?board=191.0 Bahasa Indonesia (Indonesian)]
** [https://bitcointalk.org/index.php?board=27.0 Español (Spanish)]
** [https://bitcointalk.org/index.php?board=30.0 中文 (Chinese)]
** [https://bitcointalk.org/index.php?board=201.0 Hrvatski (Croatian)]
** [https://bitcointalk.org/index.php?board=16.0 Deutsch (German)]
** [https://bitcointalk.org/index.php?board=120.0 Ελληνικά (Greek)]
** [https://bitcointalk.org/index.php?board=95.0 עברית (Hebrew)]
** [https://bitcointalk.org/index.php?board=13.0 Français]
** [https://bitcointalk.org/index.php?board=89.0 India]
** [https://bitcointalk.org/index.php?board=28.0 Italiano (Italian)]
** [https://bitcointalk.org/index.php?board=79.0 Nederlands (Dutch)]
** [https://bitcointalk.org/index.php?board=82.0 한국어 (Korean)]
** [https://bitcointalk.org/index.php?board=219.0 Philippines]
** [https://bitcointalk.org/index.php?board=142.0 Polski]
** [https://bitcointalk.org/index.php?board=29.0 Português (Portuguese)]
** [https://bitcointalk.org/index.php?board=10.0 Русский (Russian)]
** [https://bitcointalk.org/index.php?board=108.0 Română (Romanian)]
** [https://bitcointalk.org/index.php?board=45.0 Skandinavisk]
** [https://bitcointalk.org/index.php?board=133.0 Türkçe (Turkish)]
** [https://bitcointalk.org/index.php?board=11.0 Other languages/locations]
* [https://www.reddit.com/r/Bitcoin/wiki/local_communities List of Reddit local communities]

== Other ==

* [https://bitcoin.stackexchange.com Bitcoin StackExchange] - Q&A site
* [https://www.quora.com/topic/Bitcoin/ Quora - Bitcoin Questions and Answers]

==See Also==

* [[Bitcoin_Wiki:Community_portal]]

Forums

2023-11-20T23:13:09Z

Midnightmagic: removing all the dead, or attacker links.

{{Old}}

== General Bitcoin Discussion ==
* [https://bitcointalk.org/ The Bitcoin Forum]. (This is the original Bitcoin Forum, previously [https://web.archive.org/web/20091215005450/http://www.bitcoin.org:80/smf/ on bitcoin.org], where [https://bitcointalk.org/index.php?action=profile;u=3 Satoshi Nakamoto] used to [https://bitcointalk.org/index.php?action=profile;u=3;sa=showPosts post].)
* Reddit:
** [https://www.reddit.com/r/Bitcoin/ /r/Bitcoin]
** [https://www.reddit.com/r/bitcoinbeginners /r/bitcoinbeginners]
** ([https://www.reddit.com/r/Bitcoin/wiki/communities More Bitcoin subreddits])
* [https://www.tradingview.com/chat/#bitcoin TradingView Bitcoin Chat]

== Language/Region Specific ==
* [https://bitcointalk.org/#5 Local Forums], including at this time:
** [https://bitcointalk.org/index.php?board=241.0 العربية (Arabic)]
** [https://bitcointalk.org/index.php?board=191.0 Bahasa Indonesia (Indonesian)]
** [https://bitcointalk.org/index.php?board=27.0 Español (Spanish)]
** [https://bitcointalk.org/index.php?board=30.0 中文 (Chinese)]
** [https://bitcointalk.org/index.php?board=201.0 Hrvatski (Croatian)]
** [https://bitcointalk.org/index.php?board=16.0 Deutsch (German)]
** [https://bitcointalk.org/index.php?board=120.0 Ελληνικά (Greek)]
** [https://bitcointalk.org/index.php?board=95.0 עברית (Hebrew)]
** [https://bitcointalk.org/index.php?board=13.0 Français]
** [https://bitcointalk.org/index.php?board=89.0 India]
** [https://bitcointalk.org/index.php?board=28.0 Italiano (Italian)]
** [https://bitcointalk.org/index.php?board=79.0 Nederlands (Dutch)]
** [https://bitcointalk.org/index.php?board=82.0 한국어 (Korean)]
** [https://bitcointalk.org/index.php?board=219.0 Philippines]
** [https://bitcointalk.org/index.php?board=142.0 Polski]
** [https://bitcointalk.org/index.php?board=29.0 Português (Portuguese)]
** [https://bitcointalk.org/index.php?board=10.0 Русский (Russian)]
** [https://bitcointalk.org/index.php?board=108.0 Română (Romanian)]
** [https://bitcointalk.org/index.php?board=45.0 Skandinavisk]
** [https://bitcointalk.org/index.php?board=133.0 Türkçe (Turkish)]
** [https://bitcointalk.org/index.php?board=11.0 Other languages/locations]
* [https://www.reddit.com/r/Bitcoin/wiki/local_communities List of Reddit local communities]

== Other ==

* [https://bitcoin.stackexchange.com Bitcoin StackExchange] - Q&A site
* [https://www.quora.com/topic/Bitcoin/ Quora - Bitcoin Questions and Answers]

==See Also==

* [[Bitcoin_Wiki:Community_portal]]

Bitcoin Explorer

2023-09-14T22:48:20Z

Midnightmagic: Protected "Bitcoin Explorer": author removed important warnings about funds loss ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite))

==WARNING: FUNDS LOSS==

The use of specific versions of this tool to generate wallets has been [https://milksad.info/disclosure.html documented in CVE-2023-39910] to have already resulted in significant funds loss due to the inexplicable removal of the inclusion of OS randomness and replacement thereof with mere time-based seeding. The author's implication that the use of OS randomness is cryptographically equivalent to low-entropy time-only based seeding is inaccurate.

'''DO NOT USE THIS TOOL TO CREATE WALLETS NOR RECEIVE FUNDS.'''

[https://news.ycombinator.com/item?id=37057601 Additional write-up by Greg Maxwell describing some of the extent of the damage done] 
[https://archive.ph/BvGH7 Author inexplicably asserting the broken bx seed command is working as intended] 
[https://archive.is/YlwCQ Author inexplicably asserting that tdryja pointing out his error is just part of the 'core playbook'] 

'''The following page is preserved for archival purposes.'''
-----

Bitcoin Explorer (bx) is an advanced command line application that is included as part of [[Libbitcoin_Explorer|libbitcoin-explorer]]. [https://github.com/libbitcoin/libbitcoin-explorer/wiki Extensive documentation] and [https://github.com/libbitcoin/libbitcoin-explorer/wiki/Download-BX signed binaries] for Linux, OSX and Windows are available on GitHub.

==Entropy==
In versions prior to 3.8.0 bx included the '''seed''' command, which was explained in the [https://github.com/libbitcoin/libbitcoin-explorer/wiki/Random-Numbers/897620743e329ca9ae8926cba5e717122619f439 Random-Numbers] topic:

With the exception of cert-new, any BX command that requires a random number obtains that value as an argument. This places the responsibility of ensuring random number strength on end-users and also helps them understand the potential for problems... The seed command is provided as a convenience, and is the only command that generates randomness.

and was itself [https://github.com/libbitcoin/libbitcoin-explorer/wiki/bx-seed documented] with the following warning:

Generate a pseudorandom seed.
WARNING: Pseudorandom seeding can introduce cryptographic weakness into your keys. This command is provided as a convenience.

Despite this documentation, it [https://github.com/libbitcoin/libbitcoin-explorer/wiki/CVE-2023-39910 has been determined] that the command may have been used for live wallet seeding. Consequently the command has been [https://github.com/libbitcoin/libbitcoin-explorer/pull/729/commits/5281cfb370614716aa7dd1e099def193401da6f3 removed].

==Examples==
Generating a new bitcoin address:

$ echo [user entropy] | bx ec-new | bx ec-to-public | bx ec-to-address
13ua8RRSxLpL5WL5cKUDepUCvJZgGWuKh7

Executing a blockchain query against [[Libbitcoin_Server|Libbitcoin Server]] via [http://zeromq.org ZeroMQ]:

$ bx fetch-tx 4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b
transaction
{
hash 4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b
inputs
{
input
{
previous_output
{
hash 0000000000000000000000000000000000000000000000000000000000000000
index 4294967295
}
script "[ 04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73 ]"
sequence 4294967295
}
}
lock_time 0
outputs
{
output
{
address 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa
script "[ 04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f ] checksig"
value 5000000000
}
}
version 1
}

Decoding Satoshi's words:

$ bx base16-decode 04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73
ÿÿEThe Times 03/Jan/2009 Chancellor on brink of second bailout for banks

Posting a transaction directly to 10 nodes on the Bitcoin P2P network:

$ bx send-tx-p2p --nodes 10 0100000001b3807042c92f449bbf79b33ca59d7dfec7f4cc71096704a9c526dddf496ee0970100000069463044022039a36013301597daef41fbe593a02cc513d0b55527ec2df1050e2e8ff49c85c202204fcc407ce9b6f719ee7d009aeb8d8d21423f400a5b871394ca32e00c26b348dd2103c40cbd64c9c608df2c9730f49b0888c4db1c436e8b2b74aead6c6afbd10428c0ffffffff01905f0100000000001976a91418c0bd8d1818f1bf99cb1df2269c645318ef7b7388ac00000000
Sent transaction at 2015-May-08 12:17:09.
Sent transaction at 2015-May-08 12:17:09.
Sent transaction at 2015-May-08 12:17:09.
Sent transaction at 2015-May-08 12:17:12.
Sent transaction at 2015-May-08 12:17:12.
Sent transaction at 2015-May-08 12:17:15.
Sent transaction at 2015-May-08 12:17:15.
Sent transaction at 2015-May-08 12:17:19.
Sent transaction at 2015-May-08 12:17:20.
Sent transaction at 2015-May-08 12:17:20.

==See Also==
* [[Libbitcoin]]
* [[Libbitcoin_Explorer|libbitcoin-explorer]]
* [[SubvertX]]

==References==

[[Category:Clients]]
[[Category:Frontends]]
[[Category:Open Source]]
[[Category:Software‏‎]]
[[Category:User Interfaces]]

Bitcoin Explorer

2023-09-14T22:47:44Z

Midnightmagic: replacing a responsible warning of funds loss, pointers to additional information and timely twitter commentary from bx seed author

Talk:Bitcoin Explorer

2023-09-08T00:29:15Z

Midnightmagic:

* I am currently deciding how to most-appropriately re-add a warning about funds loss, as literally this is the worst possible failure mode in Bitcoin. Reverting an appropriate warning again, and especially mis-naming it vandalism will likely result in a ban. [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 00:27, 8 September 2023 (UTC)

Talk:Bitcoin Explorer

2023-09-08T00:28:14Z

Midnightmagic: pre-warning of reversion of warning removal

* I am currently deciding how to most-appropriately re-add a warning about funds loss, as literally this is the worst possible failure mode in Bitcoin. Reverting an appropriate warning again, and especially considering it vandalism will likely result in a ban. [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 00:27, 8 September 2023 (UTC)

Bitcoin Explorer

2023-08-09T21:34:39Z

Midnightmagic: sigh

= WARNING USE OF THIS SOFTWARE WILL RESULT IN YOUR FUNDS BEING STOLEN =

'''WARNING: The use of this library to generate seeds, contrary to the author's own following suggestions that include no warnings whatsoever, WILL RESULT IN YOUR FUNDS BEING STOLEN as per:'''

'''[https://milksad.info/ CVE-2023-39910 aka Milksad] archive here: [https://archive.is/KbdGI Milksad Archive]'''

'''WARNING: The author is taking zero responsibility for participating in the use of his code in critical reference materials and has taken to blaming the people who used his code to create seeds as per his own examples, in spite of this code being used widely in many non-wallet programs, examples, a widely-read book, and in suggestions in many places on Reddit.'''

'''For reference, the following is instructive:'''

* [https://github.com/libbitcoin/libbitcoin-system/commit/6d5a06e283d81260165e0eab95175069bf03b408 git commit where the author wrote vulnerable RNG code without any warnings and described it as "optimal"]
* [https://news.ycombinator.com/item?id=37057601 Additional write-up by Greg Maxwell describing some of the extent of the damage done]
* [https://archive.is/TVGrU Author asserting a 32-bit non-entropic seed to a seen gen is working as intended]
* [https://archive.is/BvGH7 Similar, "working as intended"]
* [https://archive.is/YlwCQ Author asserting it is all a part of a core conspiracy against him]

'''WARNING: The following is being left as-is for historical reference.'''

== FOR HISTORICAL REFERENCE ONLY ==

Bitcoin Explorer (bx) is an advanced command line application that is included as part of [[Libbitcoin_Explorer|libbitcoin-explorer]]. [https://github.com/libbitcoin/libbitcoin-explorer/wiki Extensive documentation] and [https://github.com/libbitcoin/libbitcoin-explorer/wiki/Download-BX signed binaries] for Linux, OSX and Windows are available on GitHub.

==Examples==
Generating a new bitcoin address:

$ bx seed | bx ec-new | bx ec-to-public | bx ec-to-address
13ua8RRSxLpL5WL5cKUDepUCvJZgGWuKh7

Executing a blockchain query against [[Libbitcoin_Server|Libbitcoin Server]] via [http://zeromq.org ZeroMQ]:

$ bx fetch-tx 4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b
transaction
{
hash 4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b
inputs
{
input
{
previous_output
{
hash 0000000000000000000000000000000000000000000000000000000000000000
index 4294967295
}
script "[ 04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73 ]"
sequence 4294967295
}
}
lock_time 0
outputs
{
output
{
address 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa
script "[ 04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f ] checksig"
value 5000000000
}
}
version 1
}

Decoding Satoshi's words:

$ bx base16-decode 04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73
ÿÿEThe Times 03/Jan/2009 Chancellor on brink of second bailout for banks

Posting a transaction directly to 10 nodes on the Bitcoin P2P network:

$ bx send-tx-p2p --nodes 10 0100000001b3807042c92f449bbf79b33ca59d7dfec7f4cc71096704a9c526dddf496ee0970100000069463044022039a36013301597daef41fbe593a02cc513d0b55527ec2df1050e2e8ff49c85c202204fcc407ce9b6f719ee7d009aeb8d8d21423f400a5b871394ca32e00c26b348dd2103c40cbd64c9c608df2c9730f49b0888c4db1c436e8b2b74aead6c6afbd10428c0ffffffff01905f0100000000001976a91418c0bd8d1818f1bf99cb1df2269c645318ef7b7388ac00000000
Sent transaction at 2015-May-08 12:17:09.
Sent transaction at 2015-May-08 12:17:09.
Sent transaction at 2015-May-08 12:17:09.
Sent transaction at 2015-May-08 12:17:12.
Sent transaction at 2015-May-08 12:17:12.
Sent transaction at 2015-May-08 12:17:15.
Sent transaction at 2015-May-08 12:17:15.
Sent transaction at 2015-May-08 12:17:19.
Sent transaction at 2015-May-08 12:17:20.
Sent transaction at 2015-May-08 12:17:20.

==See Also==
* [[Libbitcoin]]
* [[Libbitcoin_Explorer|libbitcoin-explorer]]
* [[SubvertX]]

= WARNING USE OF THIS SOFTWARE WILL RESULT IN YOUR FUNDS BEING STOLEN =

==References==

[[Category:Clients]]
[[Category:Frontends]]
[[Category:Open Source]]
[[Category:Software‏‎]]
[[Category:User Interfaces]]

Bitcoin Explorer

2023-08-09T20:24:11Z

Midnightmagic:

= WARNING USE OF THIS SOFTWARE WILL RESULT IN YOUR FUNDS BEING STOLEN =

'''WARNING: The use of this library to generate seeds, contrary to the author's own following suggestions that include no warnings whatsoever, WILL RESULT IN YOUR FUNDS BEING STOLEN as per:'''

'''[https://milksad.info/ CVE-2023-39910 aka Milksad] archive here: [https://archive.is/KbdGI Milksad Archive]'''

'''WARNING: The author is taking zero responsibility for participating in the use of his code in critical reference materials and has taken to blaming the people who used his code to create seeds as per his own examples, in spite of this code being used widely in many non-wallet programs, examples, a widely-read book, and in suggestions in many places on Reddit.'''

'''For reference, the following is instructive:'''

* [https://github.com/libbitcoin/libbitcoin-system/commit/6d5a06e283d81260165e0eab95175069bf03b408 git commit where the author wrote vulnerable RNG code without any warnings and described it as "optimal"]
* [https://news.ycombinator.com/item?id=37057601 Additional write-up by Greg Maxwell describing some of the extent of the damage done]

'''WARNING: The following is being left as-is for historical reference.'''

== FOR HISTORICAL REFERENCE ONLY ==

Bitcoin Explorer (bx) is an advanced command line application that is included as part of [[Libbitcoin_Explorer|libbitcoin-explorer]]. [https://github.com/libbitcoin/libbitcoin-explorer/wiki Extensive documentation] and [https://github.com/libbitcoin/libbitcoin-explorer/wiki/Download-BX signed binaries] for Linux, OSX and Windows are available on GitHub.

==Examples==
Generating a new bitcoin address:

$ bx seed | bx ec-new | bx ec-to-public | bx ec-to-address
13ua8RRSxLpL5WL5cKUDepUCvJZgGWuKh7

Executing a blockchain query against [[Libbitcoin_Server|Libbitcoin Server]] via [http://zeromq.org ZeroMQ]:

$ bx fetch-tx 4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b
transaction
{
hash 4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b
inputs
{
input
{
previous_output
{
hash 0000000000000000000000000000000000000000000000000000000000000000
index 4294967295
}
script "[ 04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73 ]"
sequence 4294967295
}
}
lock_time 0
outputs
{
output
{
address 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa
script "[ 04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f ] checksig"
value 5000000000
}
}
version 1
}

Decoding Satoshi's words:

$ bx base16-decode 04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73
ÿÿEThe Times 03/Jan/2009 Chancellor on brink of second bailout for banks

Posting a transaction directly to 10 nodes on the Bitcoin P2P network:

$ bx send-tx-p2p --nodes 10 0100000001b3807042c92f449bbf79b33ca59d7dfec7f4cc71096704a9c526dddf496ee0970100000069463044022039a36013301597daef41fbe593a02cc513d0b55527ec2df1050e2e8ff49c85c202204fcc407ce9b6f719ee7d009aeb8d8d21423f400a5b871394ca32e00c26b348dd2103c40cbd64c9c608df2c9730f49b0888c4db1c436e8b2b74aead6c6afbd10428c0ffffffff01905f0100000000001976a91418c0bd8d1818f1bf99cb1df2269c645318ef7b7388ac00000000
Sent transaction at 2015-May-08 12:17:09.
Sent transaction at 2015-May-08 12:17:09.
Sent transaction at 2015-May-08 12:17:09.
Sent transaction at 2015-May-08 12:17:12.
Sent transaction at 2015-May-08 12:17:12.
Sent transaction at 2015-May-08 12:17:15.
Sent transaction at 2015-May-08 12:17:15.
Sent transaction at 2015-May-08 12:17:19.
Sent transaction at 2015-May-08 12:17:20.
Sent transaction at 2015-May-08 12:17:20.

==See Also==
* [[Libbitcoin]]
* [[Libbitcoin_Explorer|libbitcoin-explorer]]
* [[SubvertX]]

= WARNING USE OF THIS SOFTWARE WILL RESULT IN YOUR FUNDS BEING STOLEN =

==References==

[[Category:Clients]]
[[Category:Frontends]]
[[Category:Open Source]]
[[Category:Software‏‎]]
[[Category:User Interfaces]]

Bitcoin Wiki:About

2022-02-20T23:36:07Z

Midnightmagic: freenode isn't really where the wiki people are anymore

This wiki is a public resource for the community of Bitcoin users, developers, and businesses as well as anyone interested in Bitcoin.

Unlike Wikipedia, the Bitcoin Wiki is not an encyclopedia, and includes things like non-encyclopedia details (e.g., exact specifications on service fees, product performance, etc), how-to manuals, protocol specifications, original research, etc. There are also no notability requirements beyond the requirement that the material be of general interest to some segment of the Bitcoin community or the Bitcoin-curious general public.

Because this resource is open to editing by the general public, readers should be aware that the material presented here often does not reflect the views of the entire Bitcoin community and may be outdated, incorrect, or outright malicious at times.

== Policies and Rules ==

* Content on the Wiki should generally be factual in nature where possible, but because Bitcoin is relatively new, many important subjects are not yet completely understood and are sometimes best described by opinion. When there is controversy, the Bitcoin wiki should teach it and explain all the major views.

* Editors should refrain from asserting ownership over an article and seek compromise where possible. Opinion pieces that are of general community interest can be posted under the user's personal namespace. Generally, if you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.

* While the Wiki doesn't exist to promote any particular businesses or commercial activity, such things are important parts of the Bitcoin ecosystem and get discussed here, but biased editing with a strong pecuniary interest is frowned upon and spamming up the wiki with referral links is prohibited.

* [[Altcoin|Non-Bitcoin alternatives]] may, at times, be discussed here, especially for comparison purposes or to illustrate a point but this wiki is a Bitcoin community resource and edits which promote competing systems may be frowned on by the community.

* To prevent unnecessary drama, editors should refrain from adding material which they believe may be unlawful for them or other editors to post. Bitcoin Wiki respects your freedom to communicate but since this is a shared resource you should respect other people's right to be free from the association with your views and their consequences.

* As a small community resource, the Bitcoin Wiki is often less formal than generic references like Wikipedia and because it addresses a broad community of interests, not all pages will be suitable for all readers: Some pages are written for a technical audience about a technical subject and wouldn't serve their intended audience if simplified for the layman. In cases where audience goals conflict and can't be resolved, we should ExpandSpace and create new pages to cover the subject from different angles if we need to. Editors should be mindful, however, of the work it takes to maintain pages and try to avoid an excessive proliferation of pages which will not be well maintained.

== Internationalization ==
This wiki uses a multi-lingual scheme similar to Wikipedia's, which means a translated article get links to its translation in the menu (in the left column from the [[Main Page]]).

If you feel one language is missing and are ready to start translating a lot of pages, you can request the creation of the language of your choice.

* [[Main Page|English]]
* French: [http://fr.bitcoin.it Français]
* Chinese: [http://zh-cn.bitcoin.it ‪中文(中国大陆)‬]
* German: [http://de.bitcoin.it Deutsch]
* Hebrew: [http://he.bitcoin.it עברית]
* Russian: [http://ru.bitcoin.it Русский]
* Spanish: [http://es.bitcoin.it Español]
* Italian: [http://it.bitcoin.it Italiano]
* Polish: [http://pl.bitcoin.it/wiki/Strona_g%C5%82%C3%B3wna Język Polski]
* Lithuanian: [[Talk:Bitcoin.it Wiki#Lithuanian|Lietuvių kalba (preparation)]]

== Backups ==

Backups used to be generated weekly, and could be downloaded from [https://dump.bitcoin.it/ the backup repository]. As of 2020 [[Bitcoin_Wiki:Issue_Tracker#dump.bitcoin.it_redirects_to_this_wiki|doesn't work]].



== Contact ==

Staff and some other editors can be contacted in [irc://irc.libera.chat/bitcoin-wiki the #bitcoin-wiki Libera IRC channel].
Please avoid contacting us to ask questions already answered on this wiki.

== License ==

When Bitcoin.it wiki was opened (on December 16th 2010), the initial license was [[wikipedia:WTFPL|WTFPL]]. It has been brought up that CC-by would be more appropriate as content from the previous wiki is under CC-by.

== Acceptable Use ==

===Links===
No affiliate/referral code links.

=== Alternative cryptocurrencies ===

Alternative cryptocurrencies (ie, besides Bitcoin) are, as a rule, considered off-topic.
Technical topics, including changes that may never be made to Bitcoin, are allowed, provided they stick to the technical topic only.
A single [[list of alternative cryptocurrencies]] is exempted from this policy.

== See Also ==
* [[:Bitcoin:Community_portal|Community portal]]

[[Category:Introduction]]

Talk:IRC channels

2022-02-20T03:46:16Z

Midnightmagic:

==Wiki IRC channel==

Would it be beneficial to have an IRC channel for this Wiki? --[[User:Firestorm|<tt><big>'''Firestorm'''</big></tt>]] 00:07, 27 May 2011 (GMT)
* Maybe, though the existing channels might be fine... --[[User:Luke-jr|Luke-jr]] 00:32, 27 May 2011 (GMT)

== Removal of Freenode links ==
I removed the Freenode links, and left a brief explanation (the Freenode nickserv and chanserv databases were dropped today, so it's no longer safe to send people there; there's no way to know what they're getting.)

I did that by editing the "Freenode IRC" template page, for simplicity. But if someone reputable in fact decides to re-register one of these channels on the Freenode side, I definitely have no objection to them adding a live link back, by splitting the template in two or just removing the template from all the other channels.

(Please do NOT re-link the channels on the Freenode side merely because they exist again, unless YOU or someone personally known and trusted to you / the community definitely has control of them.)

[[User:Gwillen|Gwillen]] ([[User talk:Gwillen|talk]]) 00:57, 15 June 2021 (UTC)

:: I've modified the IRC channel list to disambiguate the channels and help guide people towards the network they'd prefer to use. I've also added some history about Freenode and a note that the current head-honcho of the Freenode side is Luke-Jr himself, which should help people. [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 03:46, 20 February 2022 (UTC)

IRC channels

2022-02-20T03:41:51Z

Midnightmagic:

This page lists IRC channels for discussing Bitcoin-related topics. Please read: [[Bitcoin IRC Channel Guidelines]] before joining.

Freenode until 2021 has been the original home of IRC discussion and technical work on Bitcoin. In early 2021, Andrew Lee took direct control of the Freenode network and combined it with a number of other IRC networks already under his control. Within months, the majority of users of most of the old Freenode projects migrated to the new Libera network. Luke-Jr has since managed to convince the new Freenode opers that Bitcoiners should continue to maintain a successful presence on Freenode and that he could maintain it as a useful community.

==Bitcoin Project==

===Primary Discussion Areas===
====Libera Network====
{| class="wikitable"
! Channel !! Description
|-
| {{Libera IRC|bitcoin}} (on Libera) || General Bitcoin-related discussion and support. ([[Bitcoin_IRC_Channel_Guidelines |guidelines]]).
|-
| {{Libera IRC|bitcoin-core-builds}} || Discussion of the Bitcoin Core build system.
|-
| {{Libera IRC|bitcoin-core-dev}} || For development of Bitcoin Core. Log sources; [http://www.erisian.com.au/bitcoin-core-dev/ 1], [http://gnusha.org/bitcoin-core-dev/ 2] [https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2021-09-16 3]
|-
| {{Libera IRC|bitcoin-core-gui}} || For development of Bitcoin Core's GUI.
|-
| {{Libera IRC|bitcoin-core-pr-reviews}} || Weekly PR review club for discussing Bitcoin Core Pull Requests.
|-
| {{Libera IRC|bitcoin-news}} || RSS News related to Bitcoin.
|-
| {{Libera IRC|bitcoin-wizards}} (on Libera) || Bitcoin experts and futurists ([http://gnusha.org/bitcoin-wizards/ history])
|-
| {{Libera IRC|lightning-dev}} || Lightning protocol development ([http://gnusha.org/lightning-dev/ history])
|-
| {{Libera IRC|bitcoin-pricetalk}} (on Libera) || ALL Discussion Remotely Related to Bitcoin Price or other offtopic goes here
|-
| {{Libera IRC|bitcoin-wiki}} || Bitcoin Wiki support
|}

====Freenode Network====
{| class="wikitable"
! Channel !! Description
|-
| {{Freenode IRC|bitcoin}} (on Freenode) || General Bitcoin-related discussion and support. ([[Bitcoin_IRC_Channel_Guidelines |guidelines]]).
|-
| {{Freenode IRC|bitcoin-commits}} || Real-time notification of commits to Bitcoin projects.
|-
| {{Freenode IRC|bitcoin-dev}} || For general Bitcoin software development. ([http://bitcoinstats.com/irc/bitcoin-dev/logs/ history]. [[Bitcoin-dev | guidelines]])
|-
| {{Freenode IRC|bitcoin-gentoo}} || Gentoo community.
|-
| {{Freenode IRC|bitcoin-pricetalk}} (on Freenode) || ALL Discussion Remotely Related to Bitcoin Price or other offtopic goes here
|-
| {{Freenode IRC|bitcoin-watch|text=[[Bitcoin-Watch|#bitcoin-watch]]}} || Streaming Bitcoin transactions, including market data.
|-
| {{Freenode IRC|bitcoin-wizards}} (on Freenode) || Bitcoin experts and futurists ([http://gnusha.org/bitcoin-wizards/ history])
|-
| {{Freenode IRC|lnd}} || Lightning only version of #bitcoin-commits
|-
| {{Freenode IRC|sidechains-dev}} || Sidechains development
|}

===Geography-Based communities===
====Libera Network====
{| class="wikitable"
| {{Libera IRC|bitcoin-de}} || Libera German bitcoin community.
|-
| {{Libera IRC|bitcoin-hr}} || Libera Croatian language bitcoin community.
|-
| {{Libera IRC|bitcoin-fr}} || Libera French language bitcoin community.
|}
====Freenode Network====
{|class="wikitable"
! Channel !! Description
|-
| {{Freenode IRC|bitcoin-eastcoastusa}} || Freenode East Coast USA bitcoin community.
|}

===Mining Related Communities===
====Freenode Network====
{| class="wikitable"
! Channel !! Description
|-
| {{Freenode IRC|bitcoin-mining}} || Discussion and support related to mining.
|-
| {{Freenode IRC|bitcoin-fpga}} || Discussion and support specific to FPGA mining.
|-
| {{Freenode IRC|cgminer}} || Discussion and support specific to [[CGMiner]].
|-
| {{Freenode IRC|eligius}} || [[Eligius]] mining pool community (also support for [[BFGMiner]] and [[Eloipool]])
|}

===Communities for Exchanges and Trading===
====Libera Network====
{| class="wikitable"
! Channel !! Description
|-
| {{Libera IRC|bitcoin-market}} || Streaming market data (only), no chat.
|-
| {{Libera IRC|bitcoin-otc|text=[[bitcoin-otc|#bitcoin-otc]]}} || Over-the-counter trading marketplace and discussion. ([http://bitcoinstats.com/irc/bitcoin-otc/logs/ history])
|-
| {{Libera IRC|bitcoin-otc-ticker}} || Streaming market data form the [[#bitcoin-otc]] order book.
|-
| {{Libera IRC|bitcoin-otc-ratings|bitcoin-otc-ratings}} || Updates to ratings on the [[#bitcoin-otc]] Web of Trust.
|-
| {{Libera IRC|bitcoin-pit}} || Only over-the-counter trading.
|}

==Related Projects==
===Libera Network===
{| class="wikitable"
! Channel !! Description
|-
| {{Libera IRC|namecoin}} || New home of the [[Namecoin]] project.
|-
| {{Libera IRC|joinmarket}} || [[JoinMarket]], A [[CoinJoin]] implementation
|}

==See Also==

* [[Bitcoin_Wiki:Community_portal]]

[[fr:Canaux IRC]]
[[pl:Kanały IRC]]
[[ro:Canale]]

Bitcoin IRC Channel Guidelines

2022-02-20T03:38:51Z

Midnightmagic: genericizing the guidelines

The #bitcoin channels on the two IRC networks serve as the de-facto "front door" for newcomers on bitcoin.

The purpose for this channel is general discussion of everything related to bitcoin. We try to discuss and help people with everything regarding the protocol, clients, custom implementations and the philosophy behind bitcoin.

Our purpose is to help anyone with relevant discussions:

* The channel's language is English

* Please try to remain on topic: everything related to bitcoin. This means that the following topics are off-topic: alt-coins, issues about how the channel is moderated, begging, spamming, referral sites or any other form of advertising. This includes anything else that is of no interest for the majority of the users.

* Please refrain from any insults, flamewars or trolling.

* It is strictly forbidden to discuss unlawful activity.

* Generally, anything that would make a newcomer feel unwelcome or would reflect badly on the Bitcoin community should be avoided.

* There are many side channels that allow discussions on various topics. A complete list can be found on [[IRC_channels]].

* We strive to maintain a professional, friendly, and helpful atmosphere on the channel at all times. Any deviation to this might get you a warning, or booted off the channel. Feel free to discuss this with an operator in private, but do not discuss this in the main channel. Operators always have the last say in any discussion.

* Do not trust any website link given on the channel. There are many people out there trying to trick you into visiting a malicious site, or to trick you into executing viruses that are designed to search for bitcoin wallets and send the coins to the attacker. Do not click on any link unless you fully know what you are doing.

* Any url might be a scam site. Therefore we do not allow url's in general. All url shorteners are strictly forbidden as they are hiding the final url. Other sites might be allowed by the goodwill of the operators, but this is more an exception to the rule, and can be decided on case by case by the operators. Google docs in particular are currently banned automatically by one of the bots, as they have been the source of criminal activity in the past.

* We strive to provide high-quality information. Therefore we do not allow any advice on bad practices. For example: web wallets are insecure by design. Therefore, we will not recommend them as they are not as secure, and we will not allow other people to recommend them to anyone else. If in doubt ask an operator.

IRC channels

2022-02-20T03:31:50Z

Midnightmagic: best not to mix the two networks to prevent confusion, as some people may not wish to accidentally connect to one network or the other.

This page lists IRC channels for discussing Bitcoin-related topics. Please read: [[Bitcoin IRC Channel Guidelines]] before joining.

In early 2021, Andrew Lee took direct control of the Freenode network and combined it with a number of other IRC networks already under his control. Within months, the majority of users of most projects migrated to the new Libera network. Luke-Jr has since managed to convince the new Freenode opers that Bitcoiners could continue to maintain a successful presence on Freenode and maintain it as a useful community.

==Bitcoin Project==

===Primary Discussion Areas===
====Libera Network====
{| class="wikitable"
! Channel !! Description
|-
| {{Libera IRC|bitcoin}} (on Libera) || General Bitcoin-related discussion and support. ([[Bitcoin_IRC_Channel_Guidelines |guidelines]]).
|-
| {{Libera IRC|bitcoin-core-builds}} || Discussion of the Bitcoin Core build system.
|-
| {{Libera IRC|bitcoin-core-dev}} || For development of Bitcoin Core. Log sources; [http://www.erisian.com.au/bitcoin-core-dev/ 1], [http://gnusha.org/bitcoin-core-dev/ 2] [https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2021-09-16 3]
|-
| {{Libera IRC|bitcoin-core-gui}} || For development of Bitcoin Core's GUI.
|-
| {{Libera IRC|bitcoin-core-pr-reviews}} || Weekly PR review club for discussing Bitcoin Core Pull Requests.
|-
| {{Libera IRC|bitcoin-news}} || RSS News related to Bitcoin.
|-
| {{Libera IRC|bitcoin-wizards}} (on Libera) || Bitcoin experts and futurists ([http://gnusha.org/bitcoin-wizards/ history])
|-
| {{Libera IRC|lightning-dev}} || Lightning protocol development ([http://gnusha.org/lightning-dev/ history])
|-
| {{Libera IRC|bitcoin-pricetalk}} (on Libera) || ALL Discussion Remotely Related to Bitcoin Price or other offtopic goes here
|-
| {{Libera IRC|bitcoin-wiki}} || Bitcoin Wiki support
|}

====Freenode Network====
{| class="wikitable"
! Channel !! Description
|-
| {{Freenode IRC|bitcoin}} (on Freenode) || General Bitcoin-related discussion and support. ([[Bitcoin_IRC_Channel_Guidelines |guidelines]]).
|-
| {{Freenode IRC|bitcoin-commits}} || Real-time notification of commits to Bitcoin projects.
|-
| {{Freenode IRC|bitcoin-dev}} || For general Bitcoin software development. ([http://bitcoinstats.com/irc/bitcoin-dev/logs/ history]. [[Bitcoin-dev | guidelines]])
|-
| {{Freenode IRC|bitcoin-gentoo}} || Gentoo community.
|-
| {{Freenode IRC|bitcoin-pricetalk}} (on Freenode) || ALL Discussion Remotely Related to Bitcoin Price or other offtopic goes here
|-
| {{Freenode IRC|bitcoin-watch|text=[[Bitcoin-Watch|#bitcoin-watch]]}} || Streaming Bitcoin transactions, including market data.
|-
| {{Freenode IRC|bitcoin-wizards}} (on Freenode) || Bitcoin experts and futurists ([http://gnusha.org/bitcoin-wizards/ history])
|-
| {{Freenode IRC|lnd}} || Lightning only version of #bitcoin-commits
|-
| {{Freenode IRC|sidechains-dev}} || Sidechains development
|}

===Geography-Based communities===
====Libera Network====
{| class="wikitable"
| {{Libera IRC|bitcoin-de}} || Libera German bitcoin community.
|-
| {{Libera IRC|bitcoin-hr}} || Libera Croatian language bitcoin community.
|-
| {{Libera IRC|bitcoin-fr}} || Libera French language bitcoin community.
|}
====Freenode Network====
{|class="wikitable"
! Channel !! Description
|-
| {{Freenode IRC|bitcoin-eastcoastusa}} || Freenode East Coast USA bitcoin community.
|}

===Mining Related Communities===
====Freenode Network====
{| class="wikitable"
! Channel !! Description
|-
| {{Freenode IRC|bitcoin-mining}} || Discussion and support related to mining.
|-
| {{Freenode IRC|bitcoin-fpga}} || Discussion and support specific to FPGA mining.
|-
| {{Freenode IRC|cgminer}} || Discussion and support specific to [[CGMiner]].
|-
| {{Freenode IRC|eligius}} || [[Eligius]] mining pool community (also support for [[BFGMiner]] and [[Eloipool]])
|}

===Communities for Exchanges and Trading===
====Libera Network====
{| class="wikitable"
! Channel !! Description
|-
| {{Libera IRC|bitcoin-market}} || Streaming market data (only), no chat.
|-
| {{Libera IRC|bitcoin-otc|text=[[bitcoin-otc|#bitcoin-otc]]}} || Over-the-counter trading marketplace and discussion. ([http://bitcoinstats.com/irc/bitcoin-otc/logs/ history])
|-
| {{Libera IRC|bitcoin-otc-ticker}} || Streaming market data form the [[#bitcoin-otc]] order book.
|-
| {{Libera IRC|bitcoin-otc-ratings|bitcoin-otc-ratings}} || Updates to ratings on the [[#bitcoin-otc]] Web of Trust.
|-
| {{Libera IRC|bitcoin-pit}} || Only over-the-counter trading.
|}

==Related Projects==
===Libera Network===
{| class="wikitable"
! Channel !! Description
|-
| {{Libera IRC|namecoin}} || New home of the [[Namecoin]] project.
|-
| {{Libera IRC|joinmarket}} || [[JoinMarket]], A [[CoinJoin]] implementation
|}

==See Also==

* [[Bitcoin_Wiki:Community_portal]]

[[fr:Canaux IRC]]
[[pl:Kanały IRC]]
[[ro:Canale]]

Bitcoin Wiki

2022-02-20T03:24:34Z

Midnightmagic:

{{Infobox company|name=Bitcoin Wiki
|foundation=April 14, 2010
|founder=[[Martti Malmi]] (dokuwiki) [[Mark Karpelès]] (MediaWiki)
|owner=
|parent=
|assets_btc={{increase}} 506
|assets_usd={{increase}} $460.46
|assets_year=2011
|website=[http://bitcoin.it/ bitcoin.it]
|subreddit=bitcoinwiki
}}
The '''Bitcoin.it Wiki''', usually just the '''Bitcoin Wiki''', is a MediaWiki repository of Bitcoin-related knowledge. It was founded by [[Martti Malmi]] in 2010 on dokuwiki, and then later reinstated by [[Mark Karpelès]] on MediaWiki. Malmi's and Karpelès's wikis both existed simultaneously for a short time while the contents of the old wiki were transferred to the new one. The dokuwiki revisions are visible on some old pages, highlighted green.

[[File:BitcoinWiki2010.png|thumb|The Bitcoin Wiki in 2010]]In early 2011, the wiki offered a Contributor's Award which was to be shared by all members depending on work contributed. 500 bitcoins were collected, but were never distributed. They were presumed lost in the [[Mt. Gox]] hack.

Controlled supply

2022-02-20T02:09:31Z

Midnightmagic:

<blockquote>A fixed money supply, or a supply altered only in accord with objective and calculable criteria, is a necessary condition to a meaningful just price of money.<ref>[https://isidore.co/calibre/browse/book/5277 Interest and Usury] p. 220 by [https://www.jstor.org/stable/29769582 Fr. Bernard W. Dempsey, S.J.] (1903-1960); cf. John Horvat II [https://isidore.co/calibre/browse/book/5155 Return to Order] ch. 37 "The Backing of Money"</ref>
—[https://www.jstor.org/stable/29769582 Fr. Bernard W. Dempsey, S.J.] (1903-1960)</blockquote>

In a centralized economy, currency is issued by a central bank at a rate that is supposed to match the growth of the amount of goods that are exchanged so that these goods can be traded with stable prices. The
[[wikipedia:monetary base|monetary base]] is controlled by a central bank. In the United States, the [[wikipedia:Federal Reserve System|Fed]] increases the monetary base by issuing currency, increasing the amount banks have on reserve or by a process called [[wikipedia:Quantitative Easing|Quantitative Easing]].

In a fully decentralized monetary system, there is no central authority that regulates the monetary base. Instead, currency is created by the nodes of a peer-to-peer network. The Bitcoin generation algorithm defines, in advance, how currency will be created and at what rate. Any currency that is generated by a malicious user that does not follow the rules will be rejected by the network and thus is worthless.

==Currency with Finite Supply==
[[Image:Controlled supply-block reward halving.png|160px|thumb|right| Block reward halving]]
[[Image:Controlled supply-supply over block height.png|160px|thumb|right| Controlled supply]]
Bitcoins are created each time a user discovers a new [[block]].
The rate of block creation is adjusted every 2016 blocks to aim for a constant two week adjustment period (equivalent to 6 per hour.) The number of bitcoins generated per block is set to decrease geometrically, with a 50% reduction every 210,000 blocks, or approximately four years. The result is that the number of bitcoins in existence will not exceed slightly less than 21 million.<ref>[http://www.bitcointalk.org/index.php?topic=3366.msg47522#msg47522 21 million cap]</ref> Speculated justifications for the unintuitive value "21 million" are that it matches a 4-year reward halving schedule; or the ultimate total number of Satoshis that will be mined is close to the maximum capacity of a 64-bit floating point number. Satoshi has never really justified or explained many of these constants.

[[File:SupplyFormula.gif|Cumulated bitcoin supply]]

This decreasing-supply algorithm was chosen because it approximates the rate at which commodities like gold are mined. Users who use their computers to perform calculations to try and discover a block are thus called [[Mining|''Miners'']].

See also: http://bashco.github.io/Bitcoin_Monetary_Inflation/

==Projected Bitcoins Short Term ==
This chart shows the number of bitcoins that will exist in the near future. The ''Year'' is a forecast and may be slightly off.
{| class="wikitable"
|-
! Date reached!!Block!!Reward Era!! BTC/block!! Year (estimate)!! Start BTC!! BTC Added!! End BTC!! BTC Increase|| End BTC % of Limit
|-
|2009-01-03||0||1||50.00||2009||0||2625000||2625000||infinite||12.500%
|-
|2010-04-22||52500||1||50.00||2010||2625000||2625000||5250000||100.00%||25.000%
|-
|2011-01-28||105000||1||50.00||2011*||5250000||2625000||7875000||50.00%||37.500%
|-
|2011-12-14||157500||1||50.00||2012||7875000||2625000||10500000||33.33%||50.000%
|-
|[[Halving day 2012|2012-11-28]]||210000||2||25.00||2013||10500000||1312500||11812500||12.50%||56.250%
|-
|2013-10-09||262500||2||25.00||2014||11812500||1312500||13125000||11.11%||62.500%
|-
|2014-08-11||315000||2||25.00||2015||13125000||1312500||14437500||10.00%||68.750%
|-
|2015-07-29||367500||2||25.00||2016||14437500||1312500||15750000||9.09%||75.000%
|-
|2016-07-09||420000||3||12.50||2016||15750000||656250||16406250||4.17%||78.125%
|-
|2017-06-23||472500||3||12.50||2018||16406250||656250||17062500||4.00%||81.250%
|-
|2018-05-29||525000||3||12.50||2019||17062500||656250||17718750||3.85%||84.375%
|-
|2019-05-24||577500||3||12.50||2020||17718750||656250||18375000||3.70%||87.500%
|-
|2020-05-11||630000||4||6.25||2021||18375000||328125||18703125||1.79%||89.063%
|-
|2021-05-08||682500||4||6.25||2022||18703125||328125||19031250||1.75%||90.625%
|-
|||735000||4||6.25||2023||19031250||328125||19359375||1.72%||92.188%
|-
|||787500||4||6.25||2024||19359375||328125||19687500||1.69%||93.750%
|}
''* In Block 124724, user midnightmagic mined a solo block to himself which underpaid the reward by a single Satoshi and simultaneously destroyed the block's fees. This is one of two only known reductions in the total mined supply of Bitcoin. Therefore, from block 124724 onwards, all total supply estimates must technically be reduced by 1 Satoshi.

==Projected Bitcoins Long Term ==
[[Image:Controlled supply-timeline estimation.png|160px|thumb|right| Supply timeline estimation]]
Because the number of bitcoins created each time a user discovers a new block - the block reward - is halved based on a fixed interval of blocks, and the time it takes on average to discover a block can vary based on [[mining]] power and the network [[difficulty]], the exact time when the block reward is halved can vary as well. Consequently, the time the last Bitcoin will be created will also vary, and is subject to speculation based on assumptions.

If the mining power had remained constant since the first Bitcoin was mined, the last Bitcoin would have been mined somewhere near October 8th, 2140. Due to the mining power having increased overall over time, as of block 367,500 - assuming mining power remained constant from that block forward - the last Bitcoin will be mined on May 7th, 2140.

As it is very difficult to predict how mining power will evolve into the future - i.e. whether technological progress will continue to make hardware faster or whether mining will hit a a technological wall; or whether or not faster methods of SHA2 calculation will be discovered - putting an exact date or even year on this event is difficult.

The total number of bitcoins, as mentioned earlier, has an asymptote at 21 million, due to a side-effect of the data structure of the blockchain - specifically the integer storage type of the [[Transaction#general_format_.28inside_a_block.29_of_each_output_of_a_transaction_-_Txout|transaction output]], this exact value would have been 20,999,999.9769 bitcoin. Should this technical limitation be adjusted by increasing the size of the field, the total number will still only approach a maximum of 21 million.

{| class="wikitable" style="text-align:right"
|-
! Block!!Reward Era!! BTC/block!! Start BTC!! BTC Added!! End BTC!! BTC Increase|| End BTC % of Limit
|-
| 0|| 1|| 50.00000000|| 0.00000000|| 10500000.00000000|| 10500000.00000000*|| infinite|| 50.00000006%
|-
| 210000|| 2|| 25.00000000|| 10500000.00000000|| 5250000.00000000|| 15750000.00000000|| 50.00000000%|| 75.00000008%
|-
| 420000|| 3|| 12.50000000|| 15750000.00000000|| 2625000.00000000|| 18375000.00000000|| 16.66666667%|| 87.50000010%
|-
| 630000|| 4|| 6.25000000|| 18375000.00000000|| 1312500.00000000|| 19687500.00000000|| 7.14285714%|| 93.75000010%
|-
| 840000|| 5|| 3.12500000|| 19687500.00000000|| 656250.00000000|| 20343750.00000000|| 3.33333333%|| 96.87500011%
|-
| 1050000|| 6|| 1.56250000|| 20343750.00000000|| 328125.00000000|| 20671875.00000000|| 1.61290323%|| 98.43750011%
|-
| 1260000|| 7|| 0.78125000|| 20671875.00000000|| 164062.50000000|| 20835937.50000000|| 0.79365079%|| 99.21875011%
|-
| 1470000|| 8|| 0.39062500|| 20835937.50000000|| 82031.25000000|| 20917968.75000000|| 0.39370079%|| 99.60937511%
|-
| 1680000|| 9|| 0.19531250|| 20917968.75000000|| 41015.62500000|| 20958984.37500000|| 0.19607843%|| 99.80468761%
|-
| 1890000|| 10|| 0.09765625|| 20958984.37500000|| 20507.81250000|| 20979492.18750000|| 0.09784736%|| 99.90234386%
|-
| 2100000|| 11|| 0.04882812|| 20979492.18750000|| 10253.90520000|| 20989746.09270000|| 0.04887585%|| 99.95117198%
|-
| 2310000|| 12|| 0.02441406|| 20989746.09270000|| 5126.95260000|| 20994873.04530000|| 0.02442599%|| 99.97558604%
|-
| 2520000|| 13|| 0.01220703|| 20994873.04530000|| 2563.47630000|| 20997436.52160000|| 0.01221001%|| 99.98779307%
|-
| 2730000|| 14|| 0.00610351|| 20997436.52160000|| 1281.73710000|| 20998718.25870000|| 0.00610426%|| 99.99389658%
|-
| 2940000|| 15|| 0.00305175|| 20998718.25870000|| 640.86750000|| 20999359.12620000|| 0.00305194%|| 99.99694833%
|-
| 3150000|| 16|| 0.00152587|| 20999359.12620000|| 320.43270000|| 20999679.55890000|| 0.00152592%|| 99.99847420%
|-
| 3360000|| 17|| 0.00076293|| 20999679.55890000|| 160.21530000|| 20999839.77420000|| 0.00076294%|| 99.99923713%
|-
| 3570000|| 18|| 0.00038146|| 20999839.77420000|| 80.10660000|| 20999919.88080000|| 0.00038146%|| 99.99961859%
|-
| 3780000|| 19|| 0.00019073|| 20999919.88080000|| 40.05330000|| 20999959.93410000|| 0.00019073%|| 99.99980932%
|-
| 3990000|| 20|| 0.00009536|| 20999959.93410000|| 20.02560000|| 20999979.95970000|| 0.00009536%|| 99.99990468%
|-
| 4200000|| 21|| 0.00004768|| 20999979.95970000|| 10.01280000|| 20999989.97250000|| 0.00004768%|| 99.99995236%
|-
| 4410000|| 22|| 0.00002384|| 20999989.97250000|| 5.00640000|| 20999994.97890000|| 0.00002384%|| 99.99997620%
|-
| 4620000|| 23|| 0.00001192|| 20999994.97890000|| 2.50320000|| 20999997.48210000|| 0.00001192%|| 99.99998812%
|-
| 4830000|| 24|| 0.00000596|| 20999997.48210000|| 1.25160000|| 20999998.73370000|| 0.00000596%|| 99.99999408%
|-
| 5040000|| 25|| 0.00000298|| 20999998.73370000|| 0.62580000|| 20999999.35950000|| 0.00000298%|| 99.99999706%
|-
| 5250000|| 26|| 0.00000149|| 20999999.35950000|| 0.31290000|| 20999999.67240000|| 0.00000149%|| 99.99999855%
|-
| 5460000|| 27|| 0.00000074|| 20999999.67240000|| 0.15540000|| 20999999.82780000|| 0.00000074%|| 99.99999929%
|-
| 5670000|| 28|| 0.00000037|| 20999999.82780000|| 0.07770000|| 20999999.90550000|| 0.00000037%|| 99.99999966%
|-
| 5880000|| 29|| 0.00000018|| 20999999.90550000|| 0.03780000|| 20999999.94330000|| 0.00000018%|| 99.99999984%
|-
| 6090000|| 30|| 0.00000009|| 20999999.94330000|| 0.01890000|| 20999999.96220000|| 0.00000009%|| 99.99999993%
|-
| 6300000|| 31|| 0.00000004|| 20999999.96220000|| 0.00840000|| 20999999.97060000|| 0.00000004%|| 99.99999997%
|-
| 6510000|| 32|| 0.00000002|| 20999999.97060000|| 0.00420000|| 20999999.97480000|| 0.00000002%|| 99.99999999%
|-
| 6720000|| 33|| 0.00000001|| 20999999.97480000|| 0.00210000|| 20999999.97690000|| 0.00000001%|| 100.00000000%
|-
| 6930000|| 34|| 0.00000000|| 20999999.97690000|| 0.00000000|| 20999999.97690000|| 0.00000000%|| 100.00000000%
|}
''Note: The number of bitcoins are presented in a floating point format. However, these values are based on the number of satoshi per block originally in integer format to prevent compounding error.''

''* In block 124724, user midnightmagic solo mined a block which caused one less Satoshi to be created than would otherwise have come into existence. Therefore, all calculations from this block onwards must now, to be accurate, include this underpay in total Bitcoins in existence. Then, in an act of sheer stupidity, a more recent miner who failed to implement RSK properly destroyed an entire block reward of 12.5 XBT in block 501726.''

==What happens when all the bitcoins are mined?==

The bitcoin inflation rate steadily trends downwards. At the time of writing, more than 3 out of every 4 bitcoins that will ever exist have already been mined, and the annual inflation rate is just 4%. The [[block]] reward given to miners is made up of newly-created bitcoins plus [[transaction fees]]. As inflation goes to zero miners will obtain an income only from transaction fees which will provide an incentive to keep mining to make transactions [[Irreversible Transactions|irreversible]].

Due to deep technical reasons, [[Transaction_fees#The_market_for_block_space|block space is a scarce commodity]], getting a transaction mined can be seen as purchasing a portion of it. By analogy, on average every 10 minutes a fixed amount of land is created and no more, people wanting to make transactions bid for parcels of this land. The sale of this land is what supports the miners even in a zero-inflation regime. The price of this land is set by demand for transactions (because the supply is fixed and known) and the mining [[difficulty]] readjusts around this to keep the average interval at 10 minutes.

==Spendable Supply==
The theoretical total number of bitcoins, slightly less than 21 million, should not be confused with the total spendable supply. The total spendable supply is always lower than the theoretical total supply, and is subject to accidental loss, willful destruction, and technical peculiarities.

One way to see a part of the destruction of coin is by collecting a sum of all unspent transaction outputs, using a [[API reference (JSON-RPC)|Bitcoin RPC]] command <code>gettxoutsetinfo</code>. The ''total_amount'' value returned is the sum of all outputs that the client deems technically spendable but not currently spent. Note however that this does not take into account outputs that are exceedingly unlikely to be spent as is the case in loss and destruction via constructed addresses, for example.
===Miner Underpay===

The algorithm which decides whether a block is valid only checks to verify whether the total amount of the reward '''exceeds''' the reward plus available fees. Therefore it is possible for a miner to deliberately choose to underpay himself by any value: not only can this destroy the fees involved, but also the reward itself, which can prevent the total possible bitcoins that can come into existence from reaching its theoretical maximum. This is a form of underpay which the reference implementation recognises as impossible to spend. Some of the other types below are not recognised as officially destroying Bitcoins; it is possible for example to spend the 1BitcoinEaterAddressDontSendf59kuE if a corresponding private key is used (although this would imply that Bitcoin has been broken.)

===Loss of bitcoin===
Bitcoins may be lost if the conditions required to spend them are no longer known. For example, if you made a transaction to an [[address]] that requires a private key in order to spend those bitcoins further, had written that private key down on a piece of paper, but that piece of paper was lost. In this case, that bitcoin may also be considered lost, as the odds of randomly finding a matching private key are such that it is generally considered impossible.

===Willful destruction of bitcoin===
Bitcoins may also be willfully 'destroyed' - for example by attaching conditions that make it impossible to spend them.

A common method is to send bitcoin to an address that was constructed and only made to pass validity checks, but for which no private key is actually known. An example of such an address is "1BitcoinEaterAddressDontSendf59kuE", where the last "f59kuE" is text to make the preceding constructed text pass validation. Finding a matching private key is, again, generally considered impossible. For an example of how difficult this would be, see [[Vanitygen#Use_of_vanitygen_to_try_to_attack_addresses|Vanitygen]].

Another common method is to send bitcoin in a transaction where the conditions for spending are not just unfathomably unlikely, but literally impossible to meet. For example, a transaction that is made [[Script#Provably_Unspendable.2FPrunable_Outputs|provably unspendable using OP_RETURN]], or uses script operations that requires the user to prove that 1+1 equals 3.

A lesser known method is to send bitcoin to an address based on private key that is outside the [[Private_key#Range_of_valid_ECDSA_private_keys|range of valid ECDSA private keys]]. For example, the address 16QaFeudRUt8NYy2yzjm3BMvG4xBbAsBFM has a known matching private key of value 0 (zero), which is outside the valid range.

===Technical peculiarities preventing spending of bitcoin===
There are also technical peculiarities that prevent the spending of some bitcoin.

The first {{btc}}50, included in the [[genesis block]], cannot be spent as its transaction is not in the global database.

In older versions of the bitcoin reference code, a miner could make their coinbase transaction (block reward) have the exact same ID as used in a previous block<ref>https://github.com/bitcoin/bitcoin/issues/612</ref>. This effectively caused the previous block reward to become unspendable. Two known such cases<ref>{{cite tx|e3bf3d07d4b0375638d5f1db5255fe07ba2c4cb067cd81b84ee974b6585fb468|used in blocks 91722 and 91880}}</ref><ref>{{cite tx|d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599|used in blocks 91812 and 91842}}</ref> are left as special cases in the code<ref>https://github.com/bitcoin/bitcoin/commit/ab91bf39b7c11e9c86bb2043c24f0f377f1cf514</ref> as part of [[BIP 0030]] changes that fixed this issue. These transactions were {{btc}}50 each.

==Money Supply==
While the number of bitcoins in existence will never exceed slightly less than 21 million, the [[wikipedia:money supply|money supply]] of bitcoins can exceed 21 million due to [[wikipedia:Fractional-reserve banking|Fractional-reserve banking]].

==Deflation==

Because the monetary base of bitcoins cannot be expanded, the currency would be subject to severe deflation if it becomes widely used.
Keynesian economists argue that [[Deflationary spiral|deflation]] is bad for an economy because it incentivises individuals and businesses to save money rather than invest in businesses and create jobs. The [[wikipedia:Austrian school|Austrian school]] of thought counters this criticism, claiming that as deflation occurs in all stages of production, entrepreneurs who invest benefit from it. As a result, profit ratios tend to stay the same and only their magnitudes change. In other words, in a deflationary environment, goods and services decrease in price, but at the same time the cost for the production of these goods and services tend to decrease proportionally, effectively not affecting profits. Price deflation encourages an increase in hoarding — hence savings — which in turn tends to lower interest rates and increase the incentive for entrepreneurs to invest in projects of longer term.

==See also==

* [http://www.econlib.org/library/Columns/y2006/Friedmantranscript.html Milton Friedman interview], where he proposed to replace the central bank with a computer, and to fix the money supply growth at 4% annually
* [[Deflationary spiral]]
* [http://blockchain.info/charts/total-bitcoins Chart of total bitcoins in circulation]
* [[Inflation]]
* [[Prohibited changes]]

==References==
<references />

[[Category:Economics]] [[Category:Technical]]

Controlled supply

2022-02-20T02:07:50Z

Midnightmagic: Reverted edits by Geremia (talk) to last revision by Zgalli

<blockquote>A fixed money supply, or a supply altered only in accord with objective and calculable criteria, is a necessary condition to a meaningful just price of money.<ref>[https://isidore.co/calibre/browse/book/5277 Interest and Usury] p. 220 by [https://www.jstor.org/stable/29769582 Fr. Bernard W. Dempsey, S.J.] (1903-1960); cf. John Horvat II [https://isidore.co/calibre/browse/book/5155 Return to Order] ch. 37 "The Backing of Money"</ref>
—[https://www.jstor.org/stable/29769582 Fr. Bernard W. Dempsey, S.J.] (1903-1960)</blockquote>

In a centralized economy, currency is issued by a central bank at a rate that is supposed to match the growth of the amount of goods that are exchanged so that these goods can be traded with stable prices. The
[[wikipedia:monetary base|monetary base]] is controlled by a central bank. In the United States, the [[wikipedia:Federal Reserve System|Fed]] increases the monetary base by issuing currency, increasing the amount banks have on reserve or by a process called [[wikipedia:Quantitative Easing|Quantitative Easing]].

In a fully decentralized monetary system, there is no central authority that regulates the monetary base. Instead, currency is created by the nodes of a peer-to-peer network. The Bitcoin generation algorithm defines, in advance, how currency will be created and at what rate. Any currency that is generated by a malicious user that does not follow the rules will be rejected by the network and thus is worthless.

==Currency with Finite Supply==
[[Image:Controlled supply-block reward halving.png|160px|thumb|right| Block reward halving]]
[[Image:Controlled supply-supply over block height.png|160px|thumb|right| Controlled supply]]
Bitcoins are created each time a user discovers a new [[block]].
The rate of block creation is adjusted every 2016 blocks to aim for a constant two week adjustment period (equivalent to 6 per hour.) The number of bitcoins generated per block is set to decrease geometrically, with a 50% reduction every 210,000 blocks, or approximately four years. The result is that the number of bitcoins in existence will not exceed slightly less than 21 million.<ref>[http://www.bitcointalk.org/index.php?topic=3366.msg47522#msg47522 21 million cap]</ref> Speculated justifications for the unintuitive value "21 million" are that it matches a 4-year reward halving schedule; or the ultimate total number of Satoshis that will be mined is close to the maximum capacity of a 64-bit floating point number. Satoshi has never really justified or explained many of these constants.

[[File:SupplyFormula.gif|Cumulated bitcoin supply]]

This decreasing-supply algorithm was chosen because it approximates the rate at which commodities like gold are mined. Users who use their computers to perform calculations to try and discover a block are thus called [[Mining|''Miners'']].

See also: http://bashco.github.io/Bitcoin_Monetary_Inflation/

==Projected Bitcoins Short Term ==
This chart shows the number of bitcoins that will exist in the near future. The ''Year'' is a forecast and may be slightly off.
{| class="wikitable"
|-
! Date reached!!Block!!Reward Era!! BTC/block!! Year (estimate)!! Start BTC!! BTC Added!! End BTC!! BTC Increase|| End BTC % of Limit
|-
|2009-01-03||0||1||50.00||2009||0||2625000||2625000||infinite||12.500%
|-
|2010-04-22||52500||1||50.00||2010||2625000||2625000||5250000||100.00%||25.000%
|-
|2011-01-28||105000||1||50.00||2011*||5250000||2625000||7875000||50.00%||37.500%
|-
|2011-12-14||157500||1||50.00||2012||7875000||2625000||10500000||33.33%||50.000%
|-
|[[Halving day 2012|2012-11-28]]||210000||2||25.00||2013||10500000||1312500||11812500||12.50%||56.250%
|-
|2013-10-09||262500||2||25.00||2014||11812500||1312500||13125000||11.11%||62.500%
|-
|2014-08-11||315000||2||25.00||2015||13125000||1312500||14437500||10.00%||68.750%
|-
|2015-07-29||367500||2||25.00||2016||14437500||1312500||15750000||9.09%||75.000%
|-
|2016-07-09||420000||3||12.50||2016||15750000||656250||16406250||4.17%||78.125%
|-
|2017-06-23||472500||3||12.50||2018||16406250||656250||17062500||4.00%||81.250%
|-
|2018-05-29||525000||3||12.50||2019||17062500||656250||17718750||3.85%||84.375%
|-
|2019-05-24||577500||3||12.50||2020||17718750||656250||18375000||3.70%||87.500%
|-
|2020-05-11||630000||4||6.25||2021||18375000||328125||18703125||1.79%||89.063%
|-
|2021-05-08||682500||4||6.25||2022||18703125||328125||19031250||1.75%||90.625%
|-
|||735000||4||6.25||2023||19031250||328125||19359375||1.72%||92.188%
|-
|||787500||4||6.25||2024||19359375||328125||19687500||1.69%||93.750%
|}
''* In Block 124724, user midnightmagic mined a solo block to himself which underpaid the reward by a single Satoshi and simultaneously destroyed the block's fees. This is one of two only known reductions in the total mined supply of Bitcoin. Therefore, from block 124724 onwards, all total supply estimates must technically be reduced by 1 Satoshi.

==Projected Bitcoins Long Term ==
[[Image:Controlled supply-timeline estimation.png|160px|thumb|right| Supply timeline estimation]]
Because the number of bitcoins created each time a user discovers a new block - the block reward - is halved based on a fixed interval of blocks, and the time it takes on average to discover a block can vary based on [[mining]] power and the network [[difficulty]], the exact time when the block reward is halved can vary as well. Consequently, the time the last Bitcoin will be created will also vary, and is subject to speculation based on assumptions.

If the mining power had remained constant since the first Bitcoin was mined, the last Bitcoin would have been mined somewhere near October 8th, 2140. Due to the mining power having increased overall over time, as of block 367,500 - assuming mining power remained constant from that block forward - the last Bitcoin will be mined on May 7th, 2140.

As it is very difficult to predict how mining power will evolve into the future - i.e. whether technological progress will continue to make hardware faster or whether mining will hit a a technological wall; or whether or not faster methods of SHA2 calculation will be discovered - putting an exact date or even year on this event is difficult.

The total number of bitcoins, as mentioned earlier, has an asymptote at 21 million, due to a side-effect of the data structure of the blockchain - specifically the integer storage type of the [[Transaction#general_format_.28inside_a_block.29_of_each_output_of_a_transaction_-_Txout|transaction output]], this exact value would have been 20,999,999.9769 bitcoin. Should this technical limitation be adjusted by increasing the size of the field, the total number will still only approach a maximum of 21 million.

{| class="wikitable" style="text-align:right"
|-
! Block!!Reward Era!! BTC/block!! Start BTC!! BTC Added!! End BTC!! BTC Increase|| End BTC % of Limit
|-
| 0|| 1|| 50.00000000|| 0.00000000|| 10500000.00000000|| 10500000.00000000*|| infinite|| 50.00000006%
|-
| 210000|| 2|| 25.00000000|| 10500000.00000000|| 5250000.00000000|| 15750000.00000000|| 50.00000000%|| 75.00000008%
|-
| 420000|| 3|| 12.50000000|| 15750000.00000000|| 2625000.00000000|| 18375000.00000000|| 16.66666667%|| 87.50000010%
|-
| 630000|| 4|| 6.25000000|| 18375000.00000000|| 1312500.00000000|| 19687500.00000000|| 7.14285714%|| 93.75000010%
|-
| 840000|| 5|| 3.12500000|| 19687500.00000000|| 656250.00000000|| 20343750.00000000|| 3.33333333%|| 96.87500011%
|-
| 1050000|| 6|| 1.56250000|| 20343750.00000000|| 328125.00000000|| 20671875.00000000|| 1.61290323%|| 98.43750011%
|-
| 1260000|| 7|| 0.78125000|| 20671875.00000000|| 164062.50000000|| 20835937.50000000|| 0.79365079%|| 99.21875011%
|-
| 1470000|| 8|| 0.39062500|| 20835937.50000000|| 82031.25000000|| 20917968.75000000|| 0.39370079%|| 99.60937511%
|-
| 1680000|| 9|| 0.19531250|| 20917968.75000000|| 41015.62500000|| 20958984.37500000|| 0.19607843%|| 99.80468761%
|-
| 1890000|| 10|| 0.09765625|| 20958984.37500000|| 20507.81250000|| 20979492.18750000|| 0.09784736%|| 99.90234386%
|-
| 2100000|| 11|| 0.04882812|| 20979492.18750000|| 10253.90520000|| 20989746.09270000|| 0.04887585%|| 99.95117198%
|-
| 2310000|| 12|| 0.02441406|| 20989746.09270000|| 5126.95260000|| 20994873.04530000|| 0.02442599%|| 99.97558604%
|-
| 2520000|| 13|| 0.01220703|| 20994873.04530000|| 2563.47630000|| 20997436.52160000|| 0.01221001%|| 99.98779307%
|-
| 2730000|| 14|| 0.00610351|| 20997436.52160000|| 1281.73710000|| 20998718.25870000|| 0.00610426%|| 99.99389658%
|-
| 2940000|| 15|| 0.00305175|| 20998718.25870000|| 640.86750000|| 20999359.12620000|| 0.00305194%|| 99.99694833%
|-
| 3150000|| 16|| 0.00152587|| 20999359.12620000|| 320.43270000|| 20999679.55890000|| 0.00152592%|| 99.99847420%
|-
| 3360000|| 17|| 0.00076293|| 20999679.55890000|| 160.21530000|| 20999839.77420000|| 0.00076294%|| 99.99923713%
|-
| 3570000|| 18|| 0.00038146|| 20999839.77420000|| 80.10660000|| 20999919.88080000|| 0.00038146%|| 99.99961859%
|-
| 3780000|| 19|| 0.00019073|| 20999919.88080000|| 40.05330000|| 20999959.93410000|| 0.00019073%|| 99.99980932%
|-
| 3990000|| 20|| 0.00009536|| 20999959.93410000|| 20.02560000|| 20999979.95970000|| 0.00009536%|| 99.99990468%
|-
| 4200000|| 21|| 0.00004768|| 20999979.95970000|| 10.01280000|| 20999989.97250000|| 0.00004768%|| 99.99995236%
|-
| 4410000|| 22|| 0.00002384|| 20999989.97250000|| 5.00640000|| 20999994.97890000|| 0.00002384%|| 99.99997620%
|-
| 4620000|| 23|| 0.00001192|| 20999994.97890000|| 2.50320000|| 20999997.48210000|| 0.00001192%|| 99.99998812%
|-
| 4830000|| 24|| 0.00000596|| 20999997.48210000|| 1.25160000|| 20999998.73370000|| 0.00000596%|| 99.99999408%
|-
| 5040000|| 25|| 0.00000298|| 20999998.73370000|| 0.62580000|| 20999999.35950000|| 0.00000298%|| 99.99999706%
|-
| 5250000|| 26|| 0.00000149|| 20999999.35950000|| 0.31290000|| 20999999.67240000|| 0.00000149%|| 99.99999855%
|-
| 5460000|| 27|| 0.00000074|| 20999999.67240000|| 0.15540000|| 20999999.82780000|| 0.00000074%|| 99.99999929%
|-
| 5670000|| 28|| 0.00000037|| 20999999.82780000|| 0.07770000|| 20999999.90550000|| 0.00000037%|| 99.99999966%
|-
| 5880000|| 29|| 0.00000018|| 20999999.90550000|| 0.03780000|| 20999999.94330000|| 0.00000018%|| 99.99999984%
|-
| 6090000|| 30|| 0.00000009|| 20999999.94330000|| 0.01890000|| 20999999.96220000|| 0.00000009%|| 99.99999993%
|-
| 6300000|| 31|| 0.00000004|| 20999999.96220000|| 0.00840000|| 20999999.97060000|| 0.00000004%|| 99.99999997%
|-
| 6510000|| 32|| 0.00000002|| 20999999.97060000|| 0.00420000|| 20999999.97480000|| 0.00000002%|| 99.99999999%
|-
| 6720000|| 33|| 0.00000001|| 20999999.97480000|| 0.00210000|| 20999999.97690000|| 0.00000001%|| 100.00000000%
|-
| 6930000|| 34|| 0.00000000|| 20999999.97690000|| 0.00000000|| 20999999.97690000|| 0.00000000%|| 100.00000000%
|}
''Note: The number of bitcoins are presented in a floating point format. However, these values are based on the number of satoshi per block originally in integer format to prevent compounding error.''

''* In block 124724, user midnightmagic solo mined a block which caused one less Satoshi to be created than would otherwise have come into existence. Therefore, all calculations from this block onwards must now, to be accurate, include this underpay in total Bitcoins in existence. Then, in an act of sheer stupidity, a more recent miner who failed to implement RSK properly destroyed an entire block reward of 12.5 XBT in block 501726.''

==What happens when all the bitcoins are mined?==

The bitcoin inflation rate steadily trends downwards. At the time of writing, more than 3 out of every 4 bitcoins that will ever exist have already been mined, and the annual inflation rate is just 4%. The [[block]] reward given to miners is made up of newly-created bitcoins plus [[transaction fees]]. As inflation goes to zero miners will obtain an income only from transaction fees which will provide an incentive to keep mining to make transactions [[Irreversible Transactions|irreversible]].

Due to deep technical reasons, [[Transaction_fees#The_market_for_block_space|block space is a scarce commodity]], getting a transaction mined can be seen as purchasing a portion of it. By analogy, on average every 10 minutes a fixed amount of land is created and no more, people wanting to make transactions bid for parcels of this land. The sale of this land is what supports the miners even in a zero-inflation regime. The price of this land is set by demand for transactions (because the supply is fixed and known) and the mining [[difficulty]] readjusts around this to keep the average interval at 10 minutes.

==Spendable Supply==
The theoretical total number of bitcoins, slightly less than 21 million, should not be confused with the total spendable supply. The total spendable supply is always lower than the theoretical total supply, and is subject to accidental loss, willful destruction, and technical peculiarities.

One way to see a part of the destruction of coin is by collecting a sum of all unspent transaction outputs, using a [[API reference (JSON-RPC)|Bitcoin RPC]] command <code>gettxoutsetinfo</code>. The ''total_amount'' value returned is the sum of all outputs that the client deems technically spendable but not currently spent. Note however that this does not take into account outputs that are exceedingly unlikely to be spent as is the case in loss and destruction via constructed addresses, for example.
===Miner Underpay===

The algorithm which decides whether a block is valid only checks to verify whether the total amount of the reward '''exceeds''' the reward plus available fees. Therefore it is possible for a miner to deliberately choose to underpay himself by any value: not only can this destroy the fees involved, but also the reward itself, which can prevent the total possible bitcoins that can come into existence from reaching its theoretical maximum. This is a form of underpay which the reference implementation recognises as impossible to spend. Some of the other types below are not recognised as officially destroying Bitcoins; it is possible for example to spend the 1BitcoinEaterAddressDontSendf59kuE if a corresponding private key is used (although this would imply that Bitcoin has been broken.)

===Loss of bitcoin===
Bitcoins may be lost if the conditions required to spend them are no longer known. For example, if you made a transaction to an [[address]] that requires a private key in order to spend those bitcoins further, had written that private key down on a piece of paper, but that piece of paper was lost. In this case, that bitcoin may also be considered lost, as the odds of randomly finding a matching private key are such that it is generally considered impossible.

===Willful destruction of bitcoin===
Bitcoins may also be willfully 'destroyed' - for example by attaching conditions that make it impossible to spend them.

A common method is to send bitcoin to an address that was constructed and only made to pass validity checks, but for which no private key is actually known. An example of such an address is "1BitcoinEaterAddressDontSendf59kuE", where the last "f59kuE" is text to make the preceding constructed text pass validation. Finding a matching private key is, again, generally considered impossible. For an example of how difficult this would be, see [[Vanitygen#Use_of_vanitygen_to_try_to_attack_addresses|Vanitygen]].

Another common method is to send bitcoin in a transaction where the conditions for spending are not just unfathomably unlikely, but literally impossible to meet. For example, a transaction that is made [[Script#Provably_Unspendable.2FPrunable_Outputs|provably unspendable using OP_RETURN]], or uses script operations that requires the user to prove that 1+1 equals 3.

A lesser known method is to send bitcoin to an address based on private key that is outside the [[Private_key#Range_of_valid_ECDSA_private_keys|range of valid ECDSA private keys]]. For example, the address 16QaFeudRUt8NYy2yzjm3BMvG4xBbAsBFM has a known matching private key of value 0 (zero), which is outside the valid range.

===Technical peculiarities preventing spending of bitcoin===
There are also technical peculiarities that prevent the spending of some bitcoin.

The first {{btc}}50, included in the [[genesis block]], cannot be spent as its transaction is not in the global database.

In older versions of the bitcoin reference code, a miner could make their coinbase transaction (block reward) have the exact same ID as used in a previous block<ref>https://github.com/bitcoin/bitcoin/issues/612</ref>. This effectively caused the previous block reward to become unspendable. Two known such cases<ref>{{cite tx|e3bf3d07d4b0375638d5f1db5255fe07ba2c4cb067cd81b84ee974b6585fb468|used in blocks 91722 and 91880}}</ref><ref>{{cite tx|d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599|used in blocks 91812 and 91842</ref> are left as special cases in the code<ref>https://github.com/bitcoin/bitcoin/commit/ab91bf39b7c11e9c86bb2043c24f0f377f1cf514</ref> as part of [[BIP 0030]] changes that fixed this issue. These transactions were {{btc}}50 each.

==Money Supply==
While the number of bitcoins in existence will never exceed slightly less than 21 million, the [[wikipedia:money supply|money supply]] of bitcoins can exceed 21 million due to [[wikipedia:Fractional-reserve banking|Fractional-reserve banking]].

==Deflation==

Because the monetary base of bitcoins cannot be expanded, the currency would be subject to severe deflation if it becomes widely used.
Keynesian economists argue that [[Deflationary spiral|deflation]] is bad for an economy because it incentivises individuals and businesses to save money rather than invest in businesses and create jobs. The [[wikipedia:Austrian school|Austrian school]] of thought counters this criticism, claiming that as deflation occurs in all stages of production, entrepreneurs who invest benefit from it. As a result, profit ratios tend to stay the same and only their magnitudes change. In other words, in a deflationary environment, goods and services decrease in price, but at the same time the cost for the production of these goods and services tend to decrease proportionally, effectively not affecting profits. Price deflation encourages an increase in hoarding — hence savings — which in turn tends to lower interest rates and increase the incentive for entrepreneurs to invest in projects of longer term.

==See also==

* [http://www.econlib.org/library/Columns/y2006/Friedmantranscript.html Milton Friedman interview], where he proposed to replace the central bank with a computer, and to fix the money supply growth at 4% annually
* [[Deflationary spiral]]
* [http://blockchain.info/charts/total-bitcoins Chart of total bitcoins in circulation]
* [[Inflation]]
* [[Prohibited changes]]

==References==
<references />

[[Category:Economics]] [[Category:Technical]]

People

2021-08-17T03:44:28Z

Midnightmagic: this person AFAICT is not a Bitcoin contributor

A short list of active contributors to Bitcoin, ordered by first name.

[[Andreas Schildbach]] ([https://profiles.google.com/andreas.schildbach Profile]) - original developer of [https://market.android.com/details?id=de.schildbach.wallet Bitcoin Wallet for Android] ([http://code.google.com/p/bitcoin-wallet/ Google Code Project]).

[[Amir Taaki]] ([http://en.wikipedia.org/wiki/Amir_Taaki Wikipedia]) aka genjix- creator of the [[BIP]] process, [[Libbitcoin]] C++ developer toolkit, [[Libbitcoin_Server|Obelisk]] blockchain server (later BS), [[Libbitcoin_Explorer|SX]] bitcoin command line tool (later BX), [https://bitcoinmagazine.com/7892/shedding-light-on-the-dark-wallet Darkwallet], [http://www.wired.com/2014/04/darkmarket Darkmarket] (later [https://openbazaar.org OpenBazaar]), [http://reason.com/blog/2015/02/24/darkleaks-the-decentralized-information Darkleaks], [[Freecoin]] and well as inactive/defunct projects such as the [[Britcoin]] exchange, [[Intersango]] exchange, [[Spesmilo]] RPC client, [[Bitcoin Consultancy]], Bitcoin Media Blog (author), [[Vibanko]] web wallet provider, [[GLBSE]] exchange client, [https://github.com/genjix/kartludox Kartludox] Bitcoin poker client, [[Pastecoin]] and Python bindings for Bitcoin.

[[ArtForz|Art Forz]]- developed the first fully-deployed and actively-used GPU miner (Lazslo's was theoretically the first but it's not clear he solved any blocks with it) and at one time his GPU mining farm (the ArtFarm) was mining over a third of all blocks.

[[Gary Rowe]] ([https://plus.google.com/u/0/115295932487523951663/about Profile ]) - Contributor to the [[MultiBit]] (http://multibit.org) and [[BitCoinJ]] (http://code.google.com/p/bitcoinj/) projects. Working on various Bitcoin based businesses.

[[User:Gavinandresen|Gavin Andresen]] - ([https://profiles.google.com/u/0/gavinandresen/about Profile ]) Former [[Satoshi client]] maintainer. He previously worked at Silicon Graphics and now runs his own company.

[[Hal Finney]]- one of the creators of [http://en.wikipedia.org/wiki/Pretty_Good_Privacy PGP] and one of the earliest contributors to the Bitcoin project. First to identify a type of double-spending attack that now bears his name -- the [[Double-spending#Finney_attack|Finney attack]].

James McCarthy aka Nefario- creator of the first bitcoin stock exchange [[GLBSE]]

[[Jed McCaleb]], cofounder of Stellar.org and original developer of [[MtGox]]. Previously created [https://en.wikipedia.org/wiki/EDonkey2000 eDonkey2000].

[[Jeff Garzik]]- [[Satoshi client]] core developer, GPU poold software and the founder of [[Bitcoin Watch]]. Works for BitPay.

[[Luke Dashjr]] aka Luke-Jr- [[Eligius]] founder, maintains [[BFGMiner]] and maintainer of [[bitcoind]]/[[Bitcoin-Qt]] stable branches.

[[Mark Karpeles]] ([https://en.wikipedia.org/wiki/Mark_Karpeles Wikipedia]) aka MagicalTux- Former owner of [[MtGox]] and this wiki.

[[Sirius|Martti Malmi]] aka Sirius- Former Bitcoin developer. Operates the domain names bitcoin.org and bitcointalk.org.

[[Matt Corallo]] aka BlueMatt- [[Satoshi client]] and [[Bitcoinj]] developer.

[[Michael Hendrix]] aka mndrix- creator of the now defunct CoinPal and CoinCard services

[[Mike Hearn]] ([https://profiles.google.com/mh.in.england/about Profile]) Google engineer who works on Gmail and developed [[BitCoinJ]] (http://code.google.com/p/bitcoinj/) and [[Lighthouse]].

[[User:Tcatm|Nils Schneider]] aka tcatm - Bitcoin developer, owner of BitcoinWatch, creator and owner of BitcoinCharts, GPU mining software and JS web interface.

[[Patrick McFarland]] aka Diablo-D3 - DiabloMiner author, and former BitcoinTalk forum moderator.

[[Patrick Strateman]] aka phantomcircuit - Bitcoin developer, creator of [[Intersango]], member of [[Bitcoin Consultancy]] and creator of Python Bitcoin implementation.

[[Peter Todd]] - Bitcoin developer. Involved with Bitcoin related startup [[Coinkite]] and [[DarkWallet]].

[[Pieter Wuille]] aka sipa- [[Satoshi client]] developer and maintainer of the network graphs http://bitcoin.sipa.be

[[Stefan Thomas]] aka justmoon- creator of the ([https://www.weusecoins.com We Use Coins]) site/video and WebCoin.

[[Tamas Blummer]] aka grau - author of Bits of Proof, the enterprise-ready implementation of the Bitcoin protocol. http://bitsofproof.com

[[Trace Mayer]] - Host of the ([http://www.bitcoin.kn Bitcoin Knowledge Podcast]) where the top people in Bitcoin are interviewed

[[Vladimir Marchenko]]- ([https://profiles.google.com/u/0/vmartchenko/about?hl=en Profile]), runs [[Marchenko Ltd]] which sells mining contracts, previously developed the figator.org search engine.

[[Wladimir van der Laan]] - [[Satoshi client]] maintainer.

==See Also==
* [[Original client developers]]
* [[Developers]]
* [[:Template:Developers]]
* Wiki list of [[:Special:ListUsers|users]]
* [[Project:Community_portal|Community portal]]
* [[:Category:People]]

People

2021-08-17T03:42:55Z

Midnightmagic: Andrei AFAICT is not a Bitcoin contributor

A short list of active contributors to Bitcoin, ordered by first name.

[[Andreas Schildbach]] ([https://profiles.google.com/andreas.schildbach Profile]) - original developer of [https://market.android.com/details?id=de.schildbach.wallet Bitcoin Wallet for Android] ([http://code.google.com/p/bitcoin-wallet/ Google Code Project]).

[[Amir Taaki]] ([http://en.wikipedia.org/wiki/Amir_Taaki Wikipedia]) aka genjix- creator of the [[BIP]] process, [[Libbitcoin]] C++ developer toolkit, [[Libbitcoin_Server|Obelisk]] blockchain server (later BS), [[Libbitcoin_Explorer|SX]] bitcoin command line tool (later BX), [https://bitcoinmagazine.com/7892/shedding-light-on-the-dark-wallet Darkwallet], [http://www.wired.com/2014/04/darkmarket Darkmarket] (later [https://openbazaar.org OpenBazaar]), [http://reason.com/blog/2015/02/24/darkleaks-the-decentralized-information Darkleaks], [[Freecoin]] and well as inactive/defunct projects such as the [[Britcoin]] exchange, [[Intersango]] exchange, [[Spesmilo]] RPC client, [[Bitcoin Consultancy]], Bitcoin Media Blog (author), [[Vibanko]] web wallet provider, [[GLBSE]] exchange client, [https://github.com/genjix/kartludox Kartludox] Bitcoin poker client, [[Pastecoin]] and Python bindings for Bitcoin.

[[ArtForz|Art Forz]]- developed the first fully-deployed and actively-used GPU miner (Lazslo's was theoretically the first but it's not clear he solved any blocks with it) and at one time his GPU mining farm (the ArtFarm) was mining over a third of all blocks.

[[Gary Rowe]] ([https://plus.google.com/u/0/115295932487523951663/about Profile ]) - Contributor to the [[MultiBit]] (http://multibit.org) and [[BitCoinJ]] (http://code.google.com/p/bitcoinj/) projects. Working on various Bitcoin based businesses.

[[User:Gavinandresen|Gavin Andresen]] - ([https://profiles.google.com/u/0/gavinandresen/about Profile ]) Former [[Satoshi client]] maintainer. He previously worked at Silicon Graphics and now runs his own company.

[[Hal Finney]]- one of the creators of [http://en.wikipedia.org/wiki/Pretty_Good_Privacy PGP] and one of the earliest contributors to the Bitcoin project. First to identify a type of double-spending attack that now bears his name -- the [[Double-spending#Finney_attack|Finney attack]].

James McCarthy aka Nefario- creator of the first bitcoin stock exchange [[GLBSE]]

[[Jed McCaleb]], cofounder of Stellar.org and original developer of [[MtGox]]. Previously created [https://en.wikipedia.org/wiki/EDonkey2000 eDonkey2000].

[[Jeff Garzik]]- [[Satoshi client]] core developer, GPU poold software and the founder of [[Bitcoin Watch]]. Works for BitPay.

[[June Komori]] - Cybersecurity analyst and ERC20 blockchain developer, founder of [[Path Network]] and social media advisor in other projects such as Fair Token Projekt, Doge Reloaded, Projekt Diamnd, Starlink Metaverse and Shibaken Finance.

[[Luke Dashjr]] aka Luke-Jr- [[Eligius]] founder, maintains [[BFGMiner]] and maintainer of [[bitcoind]]/[[Bitcoin-Qt]] stable branches.

[[Mark Karpeles]] ([https://en.wikipedia.org/wiki/Mark_Karpeles Wikipedia]) aka MagicalTux- Former owner of [[MtGox]] and this wiki.

[[Sirius|Martti Malmi]] aka Sirius- Former Bitcoin developer. Operates the domain names bitcoin.org and bitcointalk.org.

[[Matt Corallo]] aka BlueMatt- [[Satoshi client]] and [[Bitcoinj]] developer.

[[Michael Hendrix]] aka mndrix- creator of the now defunct CoinPal and CoinCard services

[[Mike Hearn]] ([https://profiles.google.com/mh.in.england/about Profile]) Google engineer who works on Gmail and developed [[BitCoinJ]] (http://code.google.com/p/bitcoinj/) and [[Lighthouse]].

[[User:Tcatm|Nils Schneider]] aka tcatm - Bitcoin developer, owner of BitcoinWatch, creator and owner of BitcoinCharts, GPU mining software and JS web interface.

[[Patrick McFarland]] aka Diablo-D3 - DiabloMiner author, and former BitcoinTalk forum moderator.

[[Patrick Strateman]] aka phantomcircuit - Bitcoin developer, creator of [[Intersango]], member of [[Bitcoin Consultancy]] and creator of Python Bitcoin implementation.

[[Peter Todd]] - Bitcoin developer. Involved with Bitcoin related startup [[Coinkite]] and [[DarkWallet]].

[[Pieter Wuille]] aka sipa- [[Satoshi client]] developer and maintainer of the network graphs http://bitcoin.sipa.be

[[Stefan Thomas]] aka justmoon- creator of the ([https://www.weusecoins.com We Use Coins]) site/video and WebCoin.

[[Tamas Blummer]] aka grau - author of Bits of Proof, the enterprise-ready implementation of the Bitcoin protocol. http://bitsofproof.com

[[Trace Mayer]] - Host of the ([http://www.bitcoin.kn Bitcoin Knowledge Podcast]) where the top people in Bitcoin are interviewed

[[Vladimir Marchenko]]- ([https://profiles.google.com/u/0/vmartchenko/about?hl=en Profile]), runs [[Marchenko Ltd]] which sells mining contracts, previously developed the figator.org search engine.

[[Wladimir van der Laan]] - [[Satoshi client]] maintainer.

==See Also==
* [[Original client developers]]
* [[Developers]]
* [[:Template:Developers]]
* Wiki list of [[:Special:ListUsers|users]]
* [[Project:Community_portal|Community portal]]
* [[:Category:People]]

Talk:Path Network

2021-08-12T04:42:02Z

Midnightmagic: Created page with "I intend to delete this corporate page. The corporation is commercial in nature, but in any event does not seem Bitcoin related at all. ~~~~"

I intend to delete this corporate page. The corporation is commercial in nature, but in any event does not seem Bitcoin related at all. [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 04:41, 12 August 2021 (UTC)

People

2021-08-12T03:11:51Z

Midnightmagic: ArtForz appears not to have actually developed the first GPU miner, as Satoshi asked Lazslo not to start an arms race yet.

A short list of active contributors to Bitcoin, ordered by first name.

[[Andreas Schildbach]] ([https://profiles.google.com/andreas.schildbach Profile]) - original developer of [https://market.android.com/details?id=de.schildbach.wallet Bitcoin Wallet for Android] ([http://code.google.com/p/bitcoin-wallet/ Google Code Project]).

[[Andrei Popescu]]
Founder & CEO of [https://www.linkedin.com/in/andreidagospopescu SCX Holdings]. SCX Holdings is an Alternative Asset Management Co & an Investment and Intellectual Property Holding Company founded by experienced entrepreneurs and seasoned investors.

[[Amir Taaki]] ([http://en.wikipedia.org/wiki/Amir_Taaki Wikipedia]) aka genjix- creator of the [[BIP]] process, [[Libbitcoin]] C++ developer toolkit, [[Libbitcoin_Server|Obelisk]] blockchain server (later BS), [[Libbitcoin_Explorer|SX]] bitcoin command line tool (later BX), [https://bitcoinmagazine.com/7892/shedding-light-on-the-dark-wallet Darkwallet], [http://www.wired.com/2014/04/darkmarket Darkmarket] (later [https://openbazaar.org OpenBazaar]), [http://reason.com/blog/2015/02/24/darkleaks-the-decentralized-information Darkleaks], [[Freecoin]] and well as inactive/defunct projects such as the [[Britcoin]] exchange, [[Intersango]] exchange, [[Spesmilo]] RPC client, [[Bitcoin Consultancy]], Bitcoin Media Blog (author), [[Vibanko]] web wallet provider, [[GLBSE]] exchange client, [https://github.com/genjix/kartludox Kartludox] Bitcoin poker client, [[Pastecoin]] and Python bindings for Bitcoin.

[[ArtForz|Art Forz]]- developed the first fully-deployed and actively-used GPU miner (Lazslo's was theoretically the first but it's not clear he solved any blocks with it) and at one time his GPU mining farm (the ArtFarm) was mining over a third of all blocks.

[[Gary Rowe]] ([https://plus.google.com/u/0/115295932487523951663/about Profile ]) - Contributor to the [[MultiBit]] (http://multibit.org) and [[BitCoinJ]] (http://code.google.com/p/bitcoinj/) projects. Working on various Bitcoin based businesses.

[[User:Gavinandresen|Gavin Andresen]] - ([https://profiles.google.com/u/0/gavinandresen/about Profile ]) Former [[Satoshi client]] maintainer. He previously worked at Silicon Graphics and now runs his own company.

[[Hal Finney]]- one of the creators of [http://en.wikipedia.org/wiki/Pretty_Good_Privacy PGP] and one of the earliest contributors to the Bitcoin project. First to identify a type of double-spending attack that now bears his name -- the [[Double-spending#Finney_attack|Finney attack]].

James McCarthy aka Nefario- creator of the first bitcoin stock exchange [[GLBSE]]

[[Jed McCaleb]], cofounder of Stellar.org and original developer of [[MtGox]]. Previously created [https://en.wikipedia.org/wiki/EDonkey2000 eDonkey2000].

[[Jeff Garzik]]- [[Satoshi client]] core developer, GPU poold software and the founder of [[Bitcoin Watch]]. Works for BitPay.

[[June Komori]] - Cybersecurity analyst and ERC20 blockchain developer, founder of [[Path Network]] and social media advisor in other projects such as Fair Token Projekt, Doge Reloaded, Projekt Diamnd, Starlink Metaverse and Shibaken Finance.

[[Luke Dashjr]] aka Luke-Jr- [[Eligius]] founder, maintains [[BFGMiner]] and maintainer of [[bitcoind]]/[[Bitcoin-Qt]] stable branches.

[[Mark Karpeles]] ([https://en.wikipedia.org/wiki/Mark_Karpeles Wikipedia]) aka MagicalTux- Former owner of [[MtGox]] and this wiki.

[[Sirius|Martti Malmi]] aka Sirius- Former Bitcoin developer. Operates the domain names bitcoin.org and bitcointalk.org.

[[Matt Corallo]] aka BlueMatt- [[Satoshi client]] and [[Bitcoinj]] developer.

[[Michael Hendrix]] aka mndrix- creator of the now defunct CoinPal and CoinCard services

[[Mike Hearn]] ([https://profiles.google.com/mh.in.england/about Profile]) Google engineer who works on Gmail and developed [[BitCoinJ]] (http://code.google.com/p/bitcoinj/) and [[Lighthouse]].

[[User:Tcatm|Nils Schneider]] aka tcatm - Bitcoin developer, owner of BitcoinWatch, creator and owner of BitcoinCharts, GPU mining software and JS web interface.

[[Patrick McFarland]] aka Diablo-D3 - DiabloMiner author, and former BitcoinTalk forum moderator.

[[Patrick Strateman]] aka phantomcircuit - Bitcoin developer, creator of [[Intersango]], member of [[Bitcoin Consultancy]] and creator of Python Bitcoin implementation.

[[Peter Todd]] - Bitcoin developer. Involved with Bitcoin related startup [[Coinkite]] and [[DarkWallet]].

[[Pieter Wuille]] aka sipa- [[Satoshi client]] developer and maintainer of the network graphs http://bitcoin.sipa.be

[[Stefan Thomas]] aka justmoon- creator of the ([https://www.weusecoins.com We Use Coins]) site/video and WebCoin.

[[Tamas Blummer]] aka grau - author of Bits of Proof, the enterprise-ready implementation of the Bitcoin protocol. http://bitsofproof.com

[[Trace Mayer]] - Host of the ([http://www.bitcoin.kn Bitcoin Knowledge Podcast]) where the top people in Bitcoin are interviewed

[[Vladimir Marchenko]]- ([https://profiles.google.com/u/0/vmartchenko/about?hl=en Profile]), runs [[Marchenko Ltd]] which sells mining contracts, previously developed the figator.org search engine.

[[Wladimir van der Laan]] - [[Satoshi client]] maintainer.

==See Also==
* [[Original client developers]]
* [[Developers]]
* [[:Template:Developers]]
* Wiki list of [[:Special:ListUsers|users]]
* [[Project:Community_portal|Community portal]]
* [[:Category:People]]

Man page

2021-08-12T03:09:33Z

Midnightmagic:

This page should probably be deleted.

It's also a place for questions in progress, so feel free to ask new questions, or answer and/or refine existing answers.

== Ask your question here: ==

== Answered Questions ==

=== How does it work (for non-geeks) ===

====Why can't somebody just create a version of the software that gives you extra bitcoins?====

When you spend some bitcoins, the software on your machine has to prove to the software running on everybody else's machine that those bitcoins are valid.

How does it do that? Well, it is a little bit complicated; you've got to understand how bitcoins are created, and how they are traded.

First, how they're created: 6.25 bitcoins are created approximately every 10 minutes. Everybody who is trying to create bitcoins is in a race to try to find those 6.25 bitcoins; they are really hard to find, but, once found, it is easy to verify that, yes, indeed, your bitcoin software found them, so you get to spend them.

Second, how they're traded: Imagine you did find 50 bitcoins (well, your computer found them by running the bitcoin software for a few months or a year-- they are not easy to find, and are harder to find the more people who are looking for them). You trade them to me by sending them to my bitcoin address. Inside the software, a messages is created and then broadcast to everybody that says "These 50 bitcoins that we all agree are valid are hereby officially traded to somebody else (me-- well, one of my bitcoin receiving addresses, actually)."

Now I've got them. If you try to trade those same 50 bitcoins to somebody else, it won't work-- everybody running Bitcoin sees all the trades, so if you try to spend the same coins a second time everybody else's software will reject your attempt to cheat.

And that's it-- that's how it works. Bitcoins are scarce because only about 50 are created every ten minutes. And you can't claim to have more than you really have because everybody else can check to see if your coins really were created by the "race" process, or if they were from valid trades.

=== Uncatagorized ===

==== Why did this generation give me more bitcoins than normal (like 50.07)? ====

You collected a [[transaction fee]].

==== Why must users back up their wallets ====

Bitcoin transactions send bitcoins to a specific public key. A Bitcoin address is an encoded hash of a public key. In order to use received bitcoins, you need to have the private key matching the public key you received with. This is sort of like a super long password associated with an account (public key). Your Bitcoin wallet contains all of the private keys necessary for spending your received transactions. If you delete your wallet without a backup, then you no longer have the authorization information necessary to claim your coins, and the coins associated with those keys are lost forever.

Creating a new address generates a new pair of public and private keys. Each keypair is mostly random numbers, but if you are using a HD wallet with a seed, they are derived from a special seed key, so as long as you back that up, you have a good chance of recovering your complete wallet.

The situation is made somewhat more confusing because the receiving addresses shown in the UI are not the only keys in your wallet. Each Bitcoin generation is given a new public key, and, more importantly, each sent transaction also sends a random number of bitcoins back to yourself at a new key. When sending bitcoins to anyone, you generate a new keypair for yourself and simultaneously send bitcoins to your new public key and the actual recipient's public key. This is an anonymity feature -- it makes tracking Bitcoin transactions much more difficult.

So if you create a backup, send some bitcoins, and then restore from the backup, as long as you use a seed-based wallet, no bitcoins should be lost.

Linux users can setup cron by running 'crontab -e' and adding this line:
01 */1 * * * /usr/local/bin/backupwallet.sh

backupwallet.sh:
<pre>#!/usr/bin/env bash

GPGU="My GPG User"

TS=$(date "+%Y%m%d-%H-%M")

WALLET=/tmp/wallet${TS}
WALLET_E=/tmp/wallet${TS}.crypt

~/bin/bitcoind backupwallet $WALLET
/usr/bin/gpg -r "$GPGU" --output $WALLET_E --encrypt $WALLET

The shell script does:
* Call bitcoind backupwallet to create a time/date-stamped wallet file.
* GPG encrypt the wallet with my public key.

==== How many nodes are there? ====

Luke-Jr maintains a statistics page which is currently the best way to see an estimate of the current number of real nodes.

[https://luke.dashjr.org/programs/bitcoin/files/charts/software.html Luke's Node Count Pie Chart]

=== Economics ===

==== I've lost my wallet, is there a way to recreate the lost coins in the system? ====
No, coins that are lost are lost forever.
The lost coins will not be recovered or regenerated at any time.

==== Where does the value of Bitcoin stem from? What backs up Bitcoin? ====

Bitcoin has value because it is accepted as payment by many. The initial market value was achieved when people shared Bitcoins with each other, and speculated that because of its properties, the currency would be accepted by others later on.

When we say that a currency is backed up by gold, we mean that there's a promise in place that you can exchange the currency for gold. In a sense, you could say that Bitcoin is "backed up" by the price tags of merchants and currency exchangers - a price tag is a promise to exchange goods for a specified amount of currency. Of course, price tags may or may not be as long-term promises as those made by central banks or governments.

It's a common misconception that Bitcoins gain their value from the cost of electricity required to generate them. Cost doesn't equal value - hiring 1,000 men to shovel a big hole in the ground may be costly, but not valuable. Also, even though scarcity is a critical requirement for a currency to be useful, it alone doesn't make anything valuable. Your fingerprints are scarce, but that doesn't mean they have any exchange value.

At the time of this writing, Bitcoin's chain of proof is the result of over 120,000,000,000,000,000,000 cryptographically secure, verified calculations per second carried out by many independent computers. The total amount of work that has been put into Bitcoin recently passed 2^93 hashes. This large and growing input of energy and technology is part of Bitcoin's value, and represents a substantial investment of resources by Bitcoin users in creating the benefits of a trustworthy medium of exchange.

==== Isn't the minting process a waste of resources? ====

All currencies need a method for regulating the money supply and creating circulation. To make Bitcoin secure, a large amount of computer work is required. The Bitcoin process for introducing new coins into circulation is designed to make the currency secure by encouraging users to perform the necessary computational work by awarding the role of introducing new coins into circulation in rough proportion the amount of computer power contributed to this goal.

=== Technical ===

==== Can generating nodes charge different transaction fees, or is this enforced by the network? ====

Currently a generating node can charge whatever [[transaction fee]] they want. A transaction that doesn't pay the fee won't be included in any blocks produced by that node, but it will appear in later blocks by cheaper generators.

It is [http://www.bitcoin.org/smf/index.php?topic=165.msg1595#msg1595 possible] for the network to enforce a fee rate, but this is not currently implemented. If [[Satoshi]] tried to implement this, only ''generating'' nodes would have a vote in whether the change would be accepted, so the change would have to be beneficial in some way to generators (ie, not too low).

==== Does including more transactions in your block slow down your hashing rate? ====

Not at all. You're hashing the block header, which contains only a fixed-size hash of all the transactions.

==== Why is it using so much CPU? ====

If you have "Generate coins" turned on, Bitcoin will calculate millions of [[hash|hashes]] per second in an attempt to solve the current [[block]]. You will probably never solve a block with a CPU, a GPU, or even a room full of either. Best not to bother.

==== Why can't it be doing something useful for humanity instead? ====

[[hash|SHA-256 hashing]] has very specific properties that we need. In particular, it generates (with predictable CPU required) numbers that are for all practical purposes purely random, but in a way that is easily verifiable. There are no known "beneficial" calculations that could replace this.

This CPU time and electricity is not entirely wasted, though: it helps protect the network from attack.

==== Can we expand the transaction protocol so it includes a message as well as an amount? ====

Don't.

==== What happens when two nodes generate a block at the same time? ====

This is very unlikely to happen but if it does: The tiebreak is which block the NEXT block builds on.

Each node sends out it's 'winning' block. Some nodes on the network will hear about 'block A' first and assume it is the winning block, and some will hear about 'block B' first and assume it is the winning block. Then each 'half' will proceed hashing from there trying to generate the next block as normal.
If a machine with 'block B' as its predecessor wins the next race by generating 'block C', it becomes the official winner, and the nodes who were working on A give up and start on C. (In this case the generator of 'block A' might be disappointed, because he thought he generated some coins, but he didn't because the network decided his block was no longer valid.)

Note: block A and block B will usually contain the same list of transactions. Transactions not included will be made available to other future blocks for inclusion into the chain.

==== What happens if someone sends me some coins but I am not connected? ====

Any transfer to a 'valid' address should be successful.
You don't need to have a client running to receive bitcoins.
Once you create an address, any coins sent to it will just sit there waiting for you to spend them.

=== Technical (Windows) ===

==== Why am I not downloading any blocks? ====

Add bitcoin.exe to the "Excluded processes" list of Microsoft Security Essentials.

=== Developing ===

==== Is there a mailing list? ====
Yes. https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

==== Is there a test network? ====

Yes, run Bitcoin or bitcoind with the -testnet switch.

==== How do I build bitcoin? ====
Instructions for building on various platforms: https://github.com/bitcoin/bitcoin/tree/master/doc

{{fromold|more_faqs}}

[[Category:Technical]]

Man page

2021-08-12T03:07:08Z

Midnightmagic: yikes. old out of date page

This page is for frequently asked questions that do not yet appear in the [http://www.bitcoin.org/faq main FAQ]

It's also a place for questions in progress, so feel free to ask new questions, or answer and/or refine existing answers.

== Ask your question here: ==

== Answered Questions ==

=== How does it work (for non-geeks) ===

====Why can't somebody just create a version of the software that gives you extra bitcoins?====

When you spend some bitcoins, the software on your machine has to prove to the software running on everybody else's machine that those bitcoins are valid.

How does it do that? Well, it is a little bit complicated; you've got to understand how bitcoins are created, and how they are traded.

First, how they're created: 6.25 bitcoins are created approximately every 10 minutes. Everybody who is trying to create bitcoins is in a race to try to find those 6.25 bitcoins; they are really hard to find, but, once found, it is easy to verify that, yes, indeed, your bitcoin software found them, so you get to spend them.

Second, how they're traded: Imagine you did find 50 bitcoins (well, your computer found them by running the bitcoin software for a few months or a year-- they are not easy to find, and are harder to find the more people who are looking for them). You trade them to me by sending them to my bitcoin address. Inside the software, a messages is created and then broadcast to everybody that says "These 50 bitcoins that we all agree are valid are hereby officially traded to somebody else (me-- well, one of my bitcoin receiving addresses, actually)."

Now I've got them. If you try to trade those same 50 bitcoins to somebody else, it won't work-- everybody running Bitcoin sees all the trades, so if you try to spend the same coins a second time everybody else's software will reject your attempt to cheat.

And that's it-- that's how it works. Bitcoins are scarce because only about 50 are created every ten minutes. And you can't claim to have more than you really have because everybody else can check to see if your coins really were created by the "race" process, or if they were from valid trades.

=== Uncatagorized ===

==== Why did this generation give me more bitcoins than normal (like 50.07)? ====

You collected a [[transaction fee]].

==== Why must users back up their wallets ====

Bitcoin transactions send bitcoins to a specific public key. A Bitcoin address is an encoded hash of a public key. In order to use received bitcoins, you need to have the private key matching the public key you received with. This is sort of like a super long password associated with an account (public key). Your Bitcoin wallet contains all of the private keys necessary for spending your received transactions. If you delete your wallet without a backup, then you no longer have the authorization information necessary to claim your coins, and the coins associated with those keys are lost forever.

Creating a new address generates a new pair of public and private keys. Each keypair is mostly random numbers, but if you are using a HD wallet with a seed, they are derived from a special seed key, so as long as you back that up, you have a good chance of recovering your complete wallet.

The situation is made somewhat more confusing because the receiving addresses shown in the UI are not the only keys in your wallet. Each Bitcoin generation is given a new public key, and, more importantly, each sent transaction also sends a random number of bitcoins back to yourself at a new key. When sending bitcoins to anyone, you generate a new keypair for yourself and simultaneously send bitcoins to your new public key and the actual recipient's public key. This is an anonymity feature -- it makes tracking Bitcoin transactions much more difficult.

So if you create a backup, send some bitcoins, and then restore from the backup, as long as you use a seed-based wallet, no bitcoins should be lost.

Linux users can setup cron by running 'crontab -e' and adding this line:
01 */1 * * * /usr/local/bin/backupwallet.sh

backupwallet.sh:
<pre>#!/usr/bin/env bash

GPGU="My GPG User"

TS=$(date "+%Y%m%d-%H-%M")

WALLET=/tmp/wallet${TS}
WALLET_E=/tmp/wallet${TS}.crypt

~/bin/bitcoind backupwallet $WALLET
/usr/bin/gpg -r "$GPGU" --output $WALLET_E --encrypt $WALLET

The shell script does:
* Call bitcoind backupwallet to create a time/date-stamped wallet file.
* GPG encrypt the wallet with my public key.

==== How many nodes are there? ====

Luke-Jr maintains a statistics page which is currently the best way to see an estimate of the current number of real nodes.

[https://luke.dashjr.org/programs/bitcoin/files/charts/software.html Luke's Node Count Pie Chart]

=== Economics ===

==== I've lost my wallet, is there a way to recreate the lost coins in the system? ====
No, coins that are lost are lost forever.
The lost coins will not be recovered or regenerated at any time.

==== Where does the value of Bitcoin stem from? What backs up Bitcoin? ====

Bitcoin has value because it is accepted as payment by many. The initial market value was achieved when people shared Bitcoins with each other, and speculated that because of its properties, the currency would be accepted by others later on.

When we say that a currency is backed up by gold, we mean that there's a promise in place that you can exchange the currency for gold. In a sense, you could say that Bitcoin is "backed up" by the price tags of merchants and currency exchangers - a price tag is a promise to exchange goods for a specified amount of currency. Of course, price tags may or may not be as long-term promises as those made by central banks or governments.

It's a common misconception that Bitcoins gain their value from the cost of electricity required to generate them. Cost doesn't equal value - hiring 1,000 men to shovel a big hole in the ground may be costly, but not valuable. Also, even though scarcity is a critical requirement for a currency to be useful, it alone doesn't make anything valuable. Your fingerprints are scarce, but that doesn't mean they have any exchange value.

At the time of this writing, Bitcoin's chain of proof is the result of over 120,000,000,000,000,000,000 cryptographically secure, verified calculations per second carried out by many independent computers. The total amount of work that has been put into Bitcoin recently passed 2^93 hashes. This large and growing input of energy and technology is part of Bitcoin's value, and represents a substantial investment of resources by Bitcoin users in creating the benefits of a trustworthy medium of exchange.

==== Isn't the minting process a waste of resources? ====

All currencies need a method for regulating the money supply and creating circulation. To make Bitcoin secure, a large amount of computer work is required. The Bitcoin process for introducing new coins into circulation is designed to make the currency secure by encouraging users to perform the necessary computational work by awarding the role of introducing new coins into circulation in rough proportion the amount of computer power contributed to this goal.

=== Technical ===

==== Can generating nodes charge different transaction fees, or is this enforced by the network? ====

Currently a generating node can charge whatever [[transaction fee]] they want. A transaction that doesn't pay the fee won't be included in any blocks produced by that node, but it will appear in later blocks by cheaper generators.

It is [http://www.bitcoin.org/smf/index.php?topic=165.msg1595#msg1595 possible] for the network to enforce a fee rate, but this is not currently implemented. If [[Satoshi]] tried to implement this, only ''generating'' nodes would have a vote in whether the change would be accepted, so the change would have to be beneficial in some way to generators (ie, not too low).

==== Does including more transactions in your block slow down your hashing rate? ====

Not at all. You're hashing the block header, which contains only a fixed-size hash of all the transactions.

==== Why is it using so much CPU? ====

If you have "Generate coins" turned on, Bitcoin will calculate millions of [[hash|hashes]] per second in an attempt to solve the current [[block]]. You will probably never solve a block with a CPU, a GPU, or even a room full of either. Best not to bother.

==== Why can't it be doing something useful for humanity instead? ====

[[hash|SHA-256 hashing]] has very specific properties that we need. In particular, it generates (with predictable CPU required) numbers that are for all practical purposes purely random, but in a way that is easily verifiable. There are no known "beneficial" calculations that could replace this.

This CPU time and electricity is not entirely wasted, though: it helps protect the network from attack.

==== Can we expand the transaction protocol so it includes a message as well as an amount? ====

Don't.

==== What happens when two nodes generate a block at the same time? ====

This is very unlikely to happen but if it does: The tiebreak is which block the NEXT block builds on.

Each node sends out it's 'winning' block. Some nodes on the network will hear about 'block A' first and assume it is the winning block, and some will hear about 'block B' first and assume it is the winning block. Then each 'half' will proceed hashing from there trying to generate the next block as normal.
If a machine with 'block B' as its predecessor wins the next race by generating 'block C', it becomes the official winner, and the nodes who were working on A give up and start on C. (In this case the generator of 'block A' might be disappointed, because he thought he generated some coins, but he didn't because the network decided his block was no longer valid.)

Note: block A and block B will usually contain the same list of transactions. Transactions not included will be made available to other future blocks for inclusion into the chain.

==== What happens if someone sends me some coins but I am not connected? ====

Any transfer to a 'valid' address should be successful.
You don't need to have a client running to receive bitcoins.
Once you create an address, any coins sent to it will just sit there waiting for you to spend them.

=== Technical (Windows) ===

==== Why am I not downloading any blocks? ====

Add bitcoin.exe to the "Excluded processes" list of Microsoft Security Essentials.

=== Developing ===

==== Is there a mailing list? ====
Yes. https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

==== Is there a test network? ====

Yes, run Bitcoin or bitcoind with the -testnet switch.

==== How do I build bitcoin? ====
Instructions for building on various platforms: https://github.com/bitcoin/bitcoin/tree/master/doc

{{fromold|more_faqs}}

[[Category:Technical]]

Scalability FAQ

2020-10-14T20:35:55Z

Midnightmagic:

Answers to commonly-asked questions and concerns about scaling Bitcoin, including “level 1” solutions such as increasing the block size and “level 2” solutions such as the proposed Lightning network.

== Background ==

Questions about how Bitcoin currently works (related to scaling) as well as questions about the technical terminology related to the scaling discussion.

=== What is the short history of the block size limit? ===

''Note: the software now called Bitcoin Core was previously simply called “Bitcoin”.<ref>[https://bitcoin.org/en/release/v0.9.0#rebranding-to-bitcoin-core Bitcoin Core 0.9.0 release notes], Bitcoin.org, 19 March 2014</ref>''

Bitcoin Core was initially released with a 32 MiB block size limit.<ref>[https://bitcointalk.org/index.php?topic=68121 Earliest known Bitcoin code], [https://github.com/trottier/original-bitcoin/blob/92ee8d9a994391d148733da77e2bbc2f4acc43cd/src/main.h#L17 src/main.h:17] and [https://github.com/trottier/original-bitcoin/blob/92ee8d9a994391d148733da77e2bbc2f4acc43cd/src/main.cpp#L1160 src/main.cpp:1160]</ref>

Around 15 July 2010, Satoshi Nakamoto changed Bitcoin Core’s mining code so that it wouldn’t create any blocks larger than 990,000 bytes.<ref>[https://github.com/bitcoin/bitcoin/commit/a30b56ebe76ffff9f9cc8a6667186179413c6349 Bitcoin Core commit a30b56e], Satoshi Nakamoto, 15 July 2010</ref>

Two months later on 7 September 2010, Nakamoto changed Bitcoin Core’s consensus rules to reject blocks larger than 1,000,000 bytes (1 megabyte) if their block height was higher than 79,400.<ref>[https://github.com/bitcoin/bitcoin/commit/8c9479c6bbbc38b897dc97de9d04e4d5a5a36730 Bitcoin Core commit 8c9479c], Satoshi Nakamoto, 7 September 2010</ref> (Block 79,400 was later produced on 12 September 2010.<ref>[https://explorer.blockstream.com/block/000000000021d821ec06be7173f413690bc5c4bc648dfa70b3b6763236f055b7 Block height 79400], dated 12 September 2010</ref>)

Neither the July nor the September commit message explains the reason for the limit, although the careful attempt to prevent a fork may indicate Nakamoto didn’t consider it an emergency.

Nakamoto’s subsequent warning not to run a blocksize increase patch which would have destructively forked the network said that '''if''' users needed to increase the blocksize, it '''could''' be accomplished with a planned hardfork at a future time<ref>[https://bitcointalk.org/index.php?topic=1347.msg15139#msg15139 Increasing the block size if needed], Satoshi Nakamoto, 3 October 2010</ref>, but he never specified which conditions might require one.

Statements by Nakamoto in the summer of 2010 indicate he believed Bitcoin could scale to block sizes far larger than 1 megabyte. For example, on 5 August 2010, he wrote that "[W]hatever size micropayments you need will eventually be practical. I think in 5 or 10 years, the bandwidth and storage will seem trivial" and "[microtransactions] can become more practical ... if I implement client-only mode and the number of network nodes consolidates into a smaller number of professional server farms" <ref>[https://bitcointalk.org/index.php?topic=532.msg6306#msg6306 the number of network nodes consolidates into a smaller number of professional server farms]</ref>. Satoshi's reasoning was likely based on his belief that SPV would be a primary scaling mechanism. It's since been discovered that SPV security requires strong fraud proofs and the fallback requires ''full node logic.'' <ref>[https://en.bitcoin.it/wiki/User:Gmaxwell/features#Proofs Greg Maxwell's outline of fraud proof logic] Greg Maxwell's wiki page, 22 March, 2013</ref><ref>[https://bitcointalk.org/index.php?topic=96644.msg1064601#msg1064601 Greg Maxwell's early post on fraud proofs] Greg Maxwell on fraud proofs, 30 July, 2012</ref>

In one of Nakamoto's final public messages, he wrote that "Bitcoin users might get increasingly tyrannical about limiting the size of the chain so it's easy for lots of users and small devices."<ref>[https://bitcointalk.org/index.php?topic=1790.msg28917#msg28917 BitDNS and Generalizing Bitcoin], Satoshi Nakamoto, 10 December 2010</ref> This statement suggests that Nakamoto was aware of the value of limiting the block size and that he correctly predicted it was an issue that Bitcoin users would be dealing with in the future---a future Nakamoto may have known would not include him. This was in the context of Satoshi attempting to redirect to a subchain non-Bitcoin uses like DNS data which used direct on-chain block space.

=== What is this Transactions Per Second (TPS) limit? ===

The current block size limit is 1,000,000 bytes (1 megabyte)<ref>[https://github.com/bitcoin/bitcoin/blob/41076aad0cbdfa4c4cf376e345114a5c29086f81/src/consensus/consensus.h#L10 <code>MAX_BLOCK_SIZE</code>], retrieved 2 July 2015</ref>, although a small amount of that space (such as the block header) is not available to store transactions.<ref>[https://bitcoin.org/en/developer-reference#serialized-blocks Block serialization description], Bitcoin.org Developer Reference</ref>

Bitcoin transactions vary in size depending on multiple factors, such as whether they’re spending single-signature inputs or a multiple signature inputs, and how many inputs and outputs they have.

The simple way to calculate the number of Transactions Per Second (TPS) Bitcoin can handle is to divide the block size limit by the expected average size of transactions, divided by the average number of seconds between blocks (600). For example, if you assume average transactions are 250 bytes,

<pre>6.6 TPS = 1,000,000 / 250 / 600</pre>

There seems to be general agreement that Bitcoin in 2015 can handle about 3 TPS with the current average size of transactions.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/007986.html Max TPS based on current average transaction size], Mike Hearn, 8 May 2015</ref><ref name="maxwell_not_proposing">[https://www.reddit.com/r/Bitcoin/comments/39yaod/bitcoinorg_position_on_hard_forks/cs7qz5c "No one proposing 3 TPS forever"], Gregory Maxwell, 15 June 2015</ref>

Both old estimates<ref>[[Scalability]], Bitcoin Wiki, retrieved 7 July
2015</ref> and newer estimates<ref name="garzik_bip" /> placed the pre-segwit
theoretical transaction speed at about 7 TPS.

=== What do devs mean by the scaling expressions O(1), O(n), O(n2), etc…? ===

[https://en.wikipedia.org/wiki/Big_O_notation Big O notation] is a shorthand used by computer scientists to describe how well a system scales. Such descriptions are rough approximations meant to help predict potential problems and evaluate potential solutions; they are not usually expected to fully capture all variables.

* '''O(1)''' means a system has roughly the same properties no matter how big it gets.
* '''O(n)''' means that a system scales linearly: doubling the number of things (users, transactions, etc.) doubles the amount of work.
* '''O(n2)''' means that a system scales quadratically : doubling (2x) the number of things quadruples (4x) the amount of work. Often written O(n^2) is places without convenient superscripts.
* Additional examples may be found in the [https://en.wikipedia.org/wiki/Big_O_notation#Orders_of_common_functions Wikipedia article]

The following subsections show cases where big O notation has been applied to the scaling Bitcoin transaction volume.

==== O(1) block propagation ====

Bitcoin Core relays unconfirmed transactions and then later reconstructs blocks when they are mined while avoiding redundant transaction propagation. The prior transaction double-relay redundancy was eliminated with the invention of a novel block propagation algorithm called Compact Blocks <ref>[https://bitcoincore.org/en/2016/06/07/compact-blocks-faq/ Compact Blocks] Compact Blocks, BIP0152</ref> to allow miners to propagate large blocks very quickly to active network nodes and also significantly reduced miners' need for powerful bandwidth. Miners use a network<ref name="block_relay_net">[http://bitcoinrelaynetwork.org/ Matt Corallo's block relay network]</ref> that is designed for high-bandwidth Wirehair-based<ref>[https://github.com/catid/wirehair Wirehair Github Repository] Wirehair</ref> which is slightly faster still than stock Bitcoin Core.

==== O(n2) network total validation resource requirements with decentralization level held constant ====

[[File:On2_scaling_illustrated.png|thumb|right|visualization of O(n2) scaling]]

While the validation effort required per full node simply grows in O(n), the combined validation effort of all nodes grows by O(n2) '''in the domain of resource consumption'', decentralization being held constant. For a single node, it takes twice as many resources to process the transactions of twice as many users, while for all nodes it takes a combined four times as many CPU resources to process the transactions of twice as many users assuming the number of full nodes increases in proportion to the number of users.

Each on-chain Bitcoin transaction needs to be processed by each full node. If we assume that a certain percentage of users run full nodes (''n'') and that each user creates a certain number of transactions on average (''n'' again), then the network’s total resource requirements are <code>n2 = n * n</code>. In short, this means that the aggregate cost of handling all transactions on-chain quadruples each time the number of users doubles.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009199.html Total system cost], Dr. Adam Back, 28 June 2015</ref> For example,

* Imagine a network starts with 100 users and 2 total nodes (a 2% ratio).

* The network doubles in users to 200. The number of nodes also doubles to 4 (maintaining a 2% ratio of decentralized low-trust security). However, double the number of users means double the number of transactions, and each node needs to process ''every'' transaction---so each node now does double work with its bandwidth and its CPU. With double the number of nodes and double the amount of work per node, total work increases by four times.

* The network doubles again: 400 users, 8 nodes (still 2% of total), and 4 times the original workload per node for a total of 16 times as much aggregate work as the original.

* Another doubling: 800 users, 16 nodes (still 2%), and 8 times the original workload per node for a total of 64 times aggregate work as the original.

* Another doubling: 1,600 users—sixteen times the original---with 32 nodes (still 2%), and 16 times the original workload per node. The aggregate total work done by nodes is 256 times higher than it was originally.

===== Criticisms =====

Emphasis on the total validation resource requirements is suggested by some individuals to be misleading, as they claim it obfuscates the growth of the supporting base of full nodes that the total validation resource effort is split amongst. The validation resource effort made by each individual full node increases at O(n), and critics say this is the only pertinent fact with respect to scaling. Some critics also point out that the O(n2) network total validation resource requirements claim is assuming decentralization must be held constant as the network scales, and that this is not a founding principle of Bitcoin. Of course, as quoted above, Satoshi knew that decentralization would be a critical value of the safety of the system in the first place by demonstrating he could foresee multiple paths for the future of Bitcoin.

=== What’s the difference between on-chain and off-chain transactions? ===

On-chain Bitcoin transactions are those that appear in the Bitcoin block chain. Off-chain transactions are those that transfer ownership of bitcoins without putting a transaction on the block chain.

Common and proposed off-chain transactions include:

* '''Exchange transactions:''' when you buy or sell bitcoins, the exchange tracks ownership in a database without putting data in the block chain. Only when you deposit or withdraw bitcoins does the transaction appear on the block chain.
* '''Web wallet internal payments:''' many web wallets allow users of the service to pay other users of the same service using off-chain payments. For example, when one Coinbase user pays another Coinbase user. '''WARNING: Web wallets are extremely unsafe and many users have had funds stolen from them worth many hundreds of millions of dollars in today's exchange rates.'''
* '''Tipping services:''' most tipping services todayvuse off-chain transactions for everything except deposits and withdrawals from their services.
* '''Payment channels:''' channels are started using one on-chain transaction and ended using a second on-chain transaction.<ref>[https://bitcoin.org/en/developer-guide#micropayment-channel Micropayment channels], Bitcoin.org Developer Guide</ref> In between can be an essentially unlimited number of off-chain transactions as small as a single satoshi (1/100,000,000th of a bitcoin). Payment channels include those that were baked into the protocol at release as well as proposed hub-and-spoke channels and the more advanced [http://lightning.network/ Lightning network].

The vast majority of all bitcoin-denominated payments today are made off-chain.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008844.html Pure off-chain is a weak form of layer 2], Dr. Adam Back, 19 June 2015</ref>

=== What is a fee market? ===

When you create a Bitcoin transaction, you have the option to pay a [[transaction fee]]. If your software is flexible, you can pay anything from zero fees (a free transaction) to 100% of the value of the transaction (spend-to-fees). This fee is comparable to a tip. The higher it is, the bigger the incentive of the miners to incorporate your transaction into the next block.

When miners assemble a block, they are free to include whatever transactions they wish. They usually include as many as possible up to the maximum block size and then prioritize the transactions that pay the most fees per kilobyte of data.<ref name="fee_pri">[https://bitcointalk.org/index.php?topic=95837.0 Fee prioritization patch], Gavin Andresen, 26 July 2012</ref> This usually results in higher-fee transactions confirming before lower-fee transactions. If blocks become full on a regular basis, users who pay a fee that's too small will have to wait a longer and longer time for their transactions to confirm. At this point, a demand-driven fee market will arise where transactions that pay higher fees get confirmed significantly faster than transactions that pay low fees.<ref name="todd_coinwallet">[https://gist.github.com/petertodd/8e87c782bdf342ef18fb Comments on the CoinWallet.eu tx-flood stress-test], Peter Todd, 22 June 2015</ref><ref name="garzik_bip" />

In a competitive market, prices are driven by supply and demand and the emerging equilibrium price asymptotically approaches marginal costs over time. However, the current version of segwit-enabled Bitcoin limits the supply to 4 MW (4 million weight units) per block, allowing only demand to adjust. It turns out that a fee market can stabilize as long as there is a block size limit.<ref>[https://medium.com/@bergealex4/bitcoin-is-unstable-without-the-block-size-size-limit-70db07070a54 Bitcoin is unstable without a block size limit], Alex B., 24 Oct 2016</ref> Simply allowing individual miners to include as many transactions as they want is problematic due to the externalities<ref name="exernality">[https://en.wikipedia.org/wiki/Externality Definition of externality], Wikipedia, 26 January 2016</ref> of including additional blocks and explained further in section [[#Should miners be allowed to decide the block size?|'should miners be allowed to decide the block size?']] .

=== The naive way to scale Bitcoin ===

If Bitcoin decentralization is abandoned, whatever is left could scale limitlessly as a plain database-backed ledger. Mining uses enormous amounts of electricity to provide a secure, verifiable decentralized ledger and full nodes use an enormous amount of bandwidth and CPU time keeping miners honest.

To wit, if users instead decided to hand authority over to someone they trusted, mining and keeping miners honest wouldn’t be necessary. This is how Visa, MasterCard, PayPal, and the rest of the centralized payment systems works—users trust them, and they have no special difficulty scaling to [[scalability|millions of transactions an hour]]. It’s comparatively energy-efficient; it isn’t decentralized, and thus isn't efficient to the ''purpose that Bitcoin was designed to accommodate.''

=== What is a hard fork, and how does it differ from other types of forks? ===

The word fork is badly overloaded in Bitcoin development. The following terms are used, for example:

* '''[[hardfork|Hard fork]]:''' a change to the system which is not backwards compatible. Everyone needs to upgrade or things will go wrong.
* '''[[softfork|Soft fork]]:''' a change to the system which is backwards compatible as long as a majority of miners enforce it. Full nodes that don’t upgrade potentially but not necessarily have reduced security.
* '''Chain fork:''' when there are two are more blocks at the same height on a block chain. This typically happens a few times a week by accident, but it can also indicate more severe problems.
* '''[https://en.wikipedia.org/wiki/Fork_%28software_development%29 Software fork]:''' using the code from an open source project to create a different project.
* '''[https://help.github.com/articles/fork-a-repo/ Git/GitHub fork]:''' a way for developers to write and test new features before contributing them to a project.

(There are other types of software-related forks, but they don’t tend to cause as much confusion.)

=== What are the block size soft limits? ===

Bitcoin Core has historically come pre-configured to limit blocks it mines to certain sizes.<ref name="fee_pri" /> These “limits” aren’t restrictions placed on miners by other miners or nodes, but rather configuration options that help miners produce reasonably-sized blocks.

Miners can change their soft limit size (up to 4 MW) using <code>-blockmaxweight=<size></code>

Default soft limits at various times:

* '''July 2012:''' <code>-blockmaxsize</code> option created and set to default 250 KB soft limit<ref>[https://github.com/bitcoin/bitcoin/commit/c555400ca134991e39d5e3a565fcd2215abe56f6 Bitcoin Core commit c555400], Gavin Andresen, 12 July 2012</ref>
* '''November 2013:''' Raised to 750KB<ref>[https://github.com/bitcoin/bitcoin/commit/ad898b40aaf06c1cc7ac12e953805720fc9217c0 Bitcoin Core commit ad898b40], Gavin Andresen, 27 November 2013</ref>
* '''June 2015:''' Raise to 1 MB suggested<ref>[https://github.com/bitcoin/bitcoin/pull/6231 Bitcoin Core pull #6231], Chris Wheeler, 4 June 2015</ref>
* '''August 2017:''' Segwit activates at block 481824<ref>[https://explorer.blockstream.com/block/0000000000000000001c8018d9cb3b742ef25114f27563e3fc4a1902167f9893 Block 481824] August 23, 2017</ref>

== General Block Size Increase Theory ==

==== Why are some people in favour of keeping the block size conservative forever? ====

It is commonly claimed<ref name="garzik_bip" /><ref>[https://epicenterbitcoin.com/podcast/082/ Epicenter Bitcoin podcast #82], Mike Hearn (interviewed), 8 June 2015</ref> that there are people opposed to ever raising the maximum block size limit, but no Bitcoin developers have suggested a permanent blocksize.<ref name="maxwell_not_proposing" />

All developers support raising the maximum size at some point<ref>[https://www.reddit.com/r/Bitcoin/comments/39kqzs/how_about_a_softfork_optin_blocksize_increase/cs5hj8l Nothing magic about 1MB], Dr. Adam Back, 13 June 2015</ref><ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008328.html Regarding size-independent new block propagation], Pieter Wuille, 28 May 2015</ref>—they just disagree about whether now is the correct time.

==== Should miners be allowed to decide the block size? ====

A block may include as little as a single transaction, so miners can always restrict block size. Letting miners choose the maximum block size is more problematic for several reasons:

# '''Miners profit, others pay the cost:''' bigger blocks earn miners more fees, but technically miners can successfully mine without storing block data almost at all.<ref>[https://github.com/bitcoin/bitcoin/pull/5863 Bitcoin Core pull #5863 adding pruning functionality], Suhas Daftuar et al., 6 March 2015</ref> Some miners will SPV mine optimistically on other miners' blocks without even validating anyting. Other users who want full validation security, or who provide services to lightweight wallets, pay the costs of downloading and storing those larger blocks.
# '''Bigger miners can afford more bandwidth:''' each miner needs to download every transaction that they want to include in blocks,<ref name="maxwell_correcting_assumptions" /> which means that they all need high-speed connections. However, a miner with 8.3% of total hash rate can take that cost out of the about 300 BTC they make a day, while a miner with only 0.7% of total hash rate has to take that cost out of only 25 BTC a day. This means bigger miners may logically choose to make bigger blocks even though it may further centralize mining.
# '''Centralized hardware production:''' only a few companies in the world produce efficient mining equipment, and many of them have historically chosen to stop selling to the public.<ref>[http://blogs.wsj.com/venturecapital/2014/09/05/for-kncminer-time-to-forget-selling-bitcoin-machines-to-at-home-miners/ KnCMiner to stop selling to home miners], Wall Street Journal, Yuliya Chernova, 5 September 2014</ref> This prevents ordinary Bitcoin users from participating in the process even if they were willing to pay for mining equipment.
# '''Voting by hash rate favours larger miners:''' voting based on hash rate allows the current hash rate majority (or super-majority) to enforce conditions on the minority. This is similar to a lobby of large businesses being able to get laws passed that may hurt smaller businesses.<ref>[https://www.reddit.com/r/Bitcoin/comments/39kzyt/draft_bip_100_soft_fork_block_size_increase/cs5gvak Miners choosing the block size limit is ill-advised], Meni Rosenfeld, 13 June 2015</ref> This is less of an issue now that miner-signalled activation has been abandoned.
# '''Miners do not care about users:''' this was demonstrated during the [[July 2015 Forks]] where even after miners lost over $50,000 USD in income from mining invalid chains, and even after they were told that long forks harm users, they continued to mine invalid blocks.<ref>[https://bitcointalk.org/index.php?topic=700411.msg11790734#msg11790734 Intention to continue SPV mining], Wang Chun, 4 July 2015</ref>

However, there are also possible justifications for letting miners choose the block size:

# '''Authenticated participants:''' miners are active participants in Bitcoin, and they can prove it by adding data to the blocks they create.<ref>[https://bitcoin.org/en/developer-reference#term-coinbase-field Coinbase field], Bitcoin.org Developer Reference</ref> It is much harder to prove people on Reddit, BitcoinTalk, and elsewhere are real people with an active stake in Bitcoin.
# '''Bigger blocks may cost smaller miners:''' small miners and poorly-connected miners are at a disadvantage if larger blocks are produced<ref name="wuille_centralization" />, and even large and well-connected miners may find that large blocks reduce their profit percentage if the cost of bandwidth rises too high or their stale rate increases.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008355.html F2Pool block size concerns], Chun Wang, 29 May 2015</ref>

==== How could a block size increase affect user security? ====

Bitcoin’s security is highly dependent on the number of active users who protect their bitcoins with a full node like Bitcoin Core. The more active users of full nodes, the harder it is for miners to trick users into accepting fake bitcoins or other frauds.<ref>[https://medium.com/@lopp/bitcoin-nodes-how-many-is-enough-9b8e8f6fd2cf Bitcoin nodes: how many is enough?], Jameson Lopp, 7 June 2015</ref>

Full nodes need to download and verify every block, and most nodes also store blocks plus relay transactions, blocks, and filtered blocks to other users on the network. The bigger blocks become, the more difficult it becomes to do all this, so it is expected that bigger blocks will both reduce the number of users who currently run full nodes and suppress the number of users who decide to start running a full node later.<ref>[https://www.reddit.com/r/Bitcoin/comments/3bae2d/amir_taaki_on_raising_the_block_size_a_lot_of/cslcgmw Block size increases-only will create problems], Dr. Adam Back, 28 June 2015</ref>

In addition, full blocks may increase mining centralization<ref name="wuille_centralization" /> at a time when mining is already so centralized that it makes it easy to reverse transactions which have been confirmed multiple times.<ref>[http://bitcoin.stackexchange.com/questions/32562/when-to-worry-about-1-confirmation-payments/32564#32564 When to worry about one-confirmation payments], David A. Harding, 17 November 2014</ref>

==== How could larger blocks affect proof-of-work (POW) security? ====

Proof of work security is dependent on how much money miners spend on mining equipment. However, to effectively mine blocks, miners also need to spend money on bandwidth to receive new transactions and blocks created by other miners; CPUs to validate received transactions and blocks; and bandwidth to upload new blocks. These additional costs don’t directly contribute to POW security.<ref name="maxwell_correcting_assumptions">[https://www.reddit.com/r/Bitcoin/comments/39tgno/letting_miners_vote_on_the_maximum_block_size_is/cs6rek5 Correcting wrong assumptions about mining], Gregory Maxwell, 15 June 2015</ref>

As block sizes increase, the amount of bandwidth and CPU required also increases. If block sizes increase faster than the costs of bandwidth and CPU decrease, miners will have less money for POW security relative to the gross income they earn.

In addition, larger blocks have a higher risk of becoming stale (orphaned)<ref name="rusty_dsl" />, which directly correlates to lost POW security. For example, if the network average stale rate is 10%, then 10% of POW performed isn't protecting transactions on the block chain.

=== What happens if blocks aren't big enough to include all pending transactions? ===

This is already often the case, so we know that miners will simply queue transactions. The transactions eligible for block inclusion that pay the highest fee per kiloweight will be confirmed earlier than transactions that pay comparatively lower fees.<ref name="fee_pri" />

What happens from there is debated:

* BitcoinJ lead developer Mike Hearn believed in 2015 there would be “crashing nodes, a swelling transaction backlog, a sudden spike in double spending, [and] skyrocketing fees.”<ref>[https://medium.com/@octskyward/crash-landing-f5cc19908e32 Crash Landing], Mike Hearn, 7 May 2015</ref> Clearly this didn't happen, as of late 2020.
* Bitcoin Foundation chief scientist Gavin Andresen believed in 2015 that the “average transaction fee paid will rise, people or applications unwilling or unable to pay the rising fees will stop submitting transactions, [and] people and businesses will shelve plans to use Bitcoin, stunting growth and adoption.” <ref>[https://github.com/bitcoin/bitcoin/pull/6341 Bitcoin Core pull #6341], Gavin Andresen, 26 June 2015</ref> Clearly, this didn't happen either, as of late 2020.
* Bitcoin Core developer Pieter Wuille replied in 2015 to Andresen’s comment above: “Is it fair to summarize this as ‘Some use cases won’t fit any more, people will decide to no longer use the blockchain for these purposes, and the fees will adapt.’? I think that is already happening […] I don’t think we should be afraid of this change or try to stop it.” <ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009098.html The need for larger blocks], Pieter Wuille, 26 June 2015</ref>

== Segregated Witness ==

[https://en.bitcoin.it/wiki/Segregated_Witness Segregated Witness], a block size increase proposal implemented as a soft-fork and which increased the block size to 4 megabytes (actually 4 mega-weight units but strictly-speaking that is contained within 4 megabytes maximum) was adopted as the Bitcoin blocksize increase in August 2017 in block 481824<ref>[https://explorer.blockstream.com/block/0000000000000000001c8018d9cb3b742ef25114f27563e3fc4a1902167f9893 Block 481824] Block 481824</ref>. It was most favoured by the user community and the Bitcoin developers, in spite of significant political pressure against it by signalling miners and attackers. Segwit was eventually forced into activation by James Hilliard's BIP0091<ref>[https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki BIP 0091], James Hilliard, May 22, 2017.</ref>

== Specific Scaling Proposals (for historical interest) ==

=== Andresen-Hearn Block Size Increase Proposals ===

Questions about the series of related proposals by Gavin Andresen and Mike Hearn to use a hard fork to raise the maximum block size, thereby allowing miners to include more on-chain transactions. As of July 2015, the current focus was [https://github.com/bitcoin/bips/pull/163 BIP101].

==== What was the major advantage of this proposal? ====

''Bitcoin can support many more users.'' Assuming earliest possible adoption, 250 bytes per on-chain transaction, 144 blocks per day, and 2 transaction a day per user, Bitcoin can support about,

* 288,000 users in 2015
* 2,304,000 users in 2016 (800% increase)
* 4,608,000 in 2018 (1,600%)
* 9,216,000 in 2020 (3,200%)
* 18,432,000 in 2022 (6,400%)
* 36,864,000 in 2024 (12,800%)
* 73,728,000 in 2026 (25,600%)
* 147,456,000 in 2028 (51,200%)
* 294,912,000 in 2030 (102,400%)
* 589,824,000 in 2032 (204,800%)
* 1,179,648,000 in 2034 (409,600%
* 2,359,296,000 in 2036 (819,200%)

==== What is the major disadvantage of this proposal? ====

''The total cost of remaining decentralized will be high.'' Assuming earliest possible adoption and that the ratio of total users to full node operators remains the same as today, the total estimated amount of work necessary to maintain the decentralized system under the [[#O.28n2.29_network_total_validation_resource_requirements|O(2) scaling model]] will be,

* 100% of today’s work in 2015
* 6,400% in 2016
* 25,600% in 2018
* 102,400% in 2020
* 409,600% in 2022
* 1,638,400% in 2024
* 6,553,600% in 2026
* 26,214,400% in 2028
* 104,857,600% in 2030
* 419,430,400% in 2032
* 1,677,721,600% in 2034
* 6,710,886,400% in 2036

For example, if the total amount spent on running full nodes today (not counting mining) is $100 thousand per year, the estimated cost for the same level of decentralization in 2036 will be $6.7 trillion per year if validation costs stay the same. (They'll certainly go down, but algorithmic and hardware improvements probably won't eliminate an approximate 6,710,886,400% cost increase.)

==== What are the dangers of the proposed hard fork? ====

Under the then-current current proposal, 75% of miners must indicate that they agree to accept blocks up to 8 MB in size.<ref name="bip101">[https://github.com/bitcoin/bips/pull/163 BIP101], Gavin Andresen, 24 June 2016</ref> After the change goes into effect, if any miner creates a block larger than 1 MB, all nodes which have not upgraded yet will reject the block.<ref>[https://bitcoin.org/en/developer-guide#consensus-rule-changes Consensus rule changes], Bitcoin.org Developer Guide</ref>

If all full nodes have upgraded, or very close to all nodes, there should be no practical effect. If a significant number of full nodes have not upgraded, they will continue using a different block chain than the upgraded users, with the following consequences:

* Bitcoins received from before the fork can be spent twice, once on both sides of the fork. This creates a high double spend risk.
* Bitcoins received after the fork are only guaranteed to be spendable on the side of the fork they were received on. This means some users will have to lose money to restore Bitcoin to a single chain.

Users of hosted wallets (Coinbase, BlockChain.info, etc.) will use whatever block chain their host chooses. Users of lightweight P2P SPV wallets will use the [[Thin Client Security|longest chain they know of]], which may not be the actual longest chain if they only connect to nodes on the shorter chain. Users of non-P2P SPV wallets, like Electrum, will use whatever chain is used by the server they connect to.

If a bad hard fork like this happens, it will likely cause large-scale confusion and make Bitcoin very hard to use until the situation is resolved.

==== What is the deployment schedule for BIP 101? ====

* The patch needs to be accepted into Bitcoin Core, Bitcoin XT, or both.
* If accepted into Bitcoin Core, miners using that software will need to upgrade (this probably requires a new released version of Bitcoin Core). If accepted only into Bitcoin XT, miners will need to switch to using XT.
* After 75% of miners have upgraded, 8MB blocks will become allowed at the the latest of (1) 11 January 2016 or (2) two weeks after the 75% upgrade threshold.<ref name="bip101" />
* After the effective date has passed, any miner may create a block larger than 8MB. When a miner does this, upgraded full nodes will accept that block and non-upgraded full nodes will reject it, forking the network.<ref name="bip101" /> See [[#What_are_the_dangers_of_the_proposed_hard_fork.3F|hard fork dangers]] for what his might mean.

==== Will miners go straight from 1 MB blocks to 8 MB blocks? ====

That would be highly unlikely. Uploading an 8 MB block currently takes significantly more time than uploading a 1 MB block<ref name="rusty_dsl">[http://rusty.ozlabs.org/?p=509 Mining on a home DSL connection test results], Rusty Russell, 19 June 2015</ref>, even with the roughly 25x reduction in size available from use of Matt Corallo’s block relay network.<ref name="block_relay_net" />

The longer it takes to upload a block, the higher the risk it will become a stale block—meaning the miner who created it will not receive the block subsidy or transaction fees (currently about 25 BTC per block).

However, if technology like Invertible Bloom Lookup Tables (IBLTs) is deployed and found to work as expected<ref name="iblt">[https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2 O(1) block propagation], Gavin Andresen, 8 August 2014</ref>, or if mining [[#What_is_the_most_efficient_way_to_scale_Bitcoin.3F|centralizes further]], adding additional transactions may not have a significant enough cost to discourage miners from creating full blocks. In that case, blocks will be filled as soon as there are enough people wanting to make transactions paying the default relay fee<ref>[https://github.com/bitcoin/bitcoin/pull/3305 Bitcoin Core pull #3305 dropping default fees], Mike Hearn, 22 November 2013</ref> of 0.00001000 BTC/kilobyte.

==== What tests have been performed related to this proposal? ====

* '''20MB block processing''' (Gavin Andresen) “if we increased the maximum block size to 20 megabytes tomorrow, and every single miner decided to start creating 20MB blocks and there was a sudden increase in the number of transactions on the network to fill up those blocks… the 0.10.0 version of [Bitcoin Core] would run just fine.”<ref>[http://gavintech.blogspot.com/2015/01/twenty-megabytes-testing-results.html Twenty megabyte block testing], Gavin Andresen, 20 January 2015</ref> (ellipses in original)
* '''Mining & relay simulation''' (Gavin Andresen) “if blocks take 20 seconds to propagate, a network with a miner that has 30% of the hashing power will get 30.3% of the blocks.”<ref>[http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners Are bigger blocks better for bigger miners?], Gavin Andresen, 22 May 2015</ref>
* '''Mining on a home DSL connection''' (Rusty Russell) “Using the rough formula of 1-exp(-t/600), I would expect orphan rates of 10.5% generating 1MB blocks, and 56.6% with 8MB blocks; that’s a huge cut in expected profits.”<ref name="rusty_dsl" />
* '''Mining centralization pressure''' (Pieter Wuille) “[This] does very clearly show the effects of larger blocks on centralization pressure of the system.”<ref name="wuille_centralization">[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008581.html Mining centralization pressure from non-uniform propagation speed], Pieter Wuille, 12 June 2015</ref>

=== Garzik Miner Block Size Voting Proposal (AKA BIP100) ===

''Note, BIP 100 is the marketing name for this proposal. No BIP number
has yet been publicly requested, and the number assigned is unlikely to
be 100.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-May/005756.html
Prenumbered BIP naming], Gregory Maxwell, 12 May 2014</ref>''

Questions related to Jeff Garzik's proposal<ref name="garzik_bip">[http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf Draft BIP: decentralized economic policy], Jeff Garzik, 12 June 2015 (revised 15 June 2015)</ref> to allow miners to vote on raising and lowering the maximum block size.

==== What does this proposal do? ====

# It creates a one-time hard fork that does not automatically change the maximum block size.

# It allows miners to vote to increase or decrease the maximum block size within the range of 1MB to 32MB. These changes are neither hard forks nor soft forks, but simply rules that all nodes should know about after the initial hard fork.

==== Does it reduce the risk of a hard fork? ====

Hard forks are most dangerous when they're done without strong
consensus.<ref name="garzik_bip" /><ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008779.html Consensus changes are not about making a change to the software],
Pieter Wuille, 18 June 2015</ref>

If Garzik's proposal gains strong consensus, it will be as safe as possible
for a hard fork and it will allow increasing the block size up to 32 MB
without any additional risk of a fork.

==== Why is it limited to 32 megabytes? ====

According to the draft BIP, "the 32 MB hard fork is largely coincidental -- a whole network upgrade at 32 MB was likely needed anyway."

=== Lightning Network ===

Questions related to using the proposed [http://lightning.network/ Lightning network] as a way to scale the number of users Bitcoin can support.

==== How does transaction security differ from that of Bitcoin? ====

Transactions on the proposed Lightning network use Bitcoin transactions exclusively to transfer bitcoins<ref name="russell_lightning1">[http://rusty.ozlabs.org/?p=450 Lightning Networks: Part I], Rusty Russell, 30 March 2015</ref>, and so the same security as regular Bitcoin transactions is provided when both a Lightning hub and client are cooperating.

When a Lightning hub or client refuses to cooperate with the other (maybe because they accidentally went offline), the other party can still receive their full 100% bitcoin balance by closing the payment channel—but they must first wait for a defined amount of time mutually chosen by both the hub and client.<ref>[http://rusty.ozlabs.org/?p=462 Lightning Networks: Part II], Rusty Russell, 1 April 2015</ref>

If one party waits too long to close the payment channel, the other party may be able to steal bitcoins. However, it is possible to delegate the task of closing the channel in an emergency to an unlimited number of hubs around the Internet, so closing the channel on time should be easy.<ref name="russell_lightning4">[http://rusty.ozlabs.org/?p=477 Lightning Networks: Part IV], Rusty Russell, 8 April 2015</ref>

In summary, provided that payment channels are closed on time, the worst that can happen to users is that they may have to wait a few weeks for a channel to fully close before spending the bitcoins they received from it. Their security is otherwise the same as with regular Bitcoin.

For Lightning hubs, security is slightly worse in the sense that they need to keep a potentially-large amount of funds in a hot wallet<ref name="lightning_paper">[http://lightning.network/lightning-network-paper-DRAFT-0.5.pdf Lightning Network (Draft 0.5)], Section 6.3: Coin Theft via Hacking, Joseph Poon and Thaddeus Dryja</ref>, so they can’t take advantage of the anti-hacking protection offered by cold wallets. Otherwise, Lightning hubs have the same security as clients.

==== When will Lightning be ready for use? ====

Lightning requires a basic test implementation (work underway<ref>[https://lists.blockstream.com/pipermail/lightning-dev/2015-June/000018.html Lightning first steps], Rusty Russell, 13 June 2015</ref>), several soft-fork changes to the Bitcoin protocol (work underway<ref>[https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65: CheckLockTimeVerify], Peter Todd, 1 October 2014</ref><ref>[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68: Consensus-enforced transaction replacement], Mark Friedenbach, 28 May 2015</ref>, and wallets need to be updated to support the Lightning network protocol.<ref name="russell_lightning4" />

Dr. Adam Back has said, "I expect we can get something running inside a year."<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009242.html Reply to Andresen regarding Lightning], Dr. Adam Back, 28 June 2015</ref>

==== Doesn’t Lightning require bigger blocks anyway? ====

Lightning is block-size neutral. It requires one on-chain transaction to open a channel between a hub and a client, and one on-chain transaction to close a channel.<ref name="russell_lightning1" /> In between it can support an unlimited number of transactions between anyone on the Lightning network.<ref name="lightning_paper" />

Using the numbers from the Lightning presentation<ref name="lightning_slides">[http://lightning.network/lightning-network.pdf Lightning presentation], Joseph Poon, 23 February 2015</ref>, if people open and close a plausible two channels a year, Lightning can support about 52 million users with the current one-megabyte limit—and each user can make an unlimited number of transactions. Currently, assuming people make an average of only two Bitcoin transactions a day, basic Bitcoin can support only 288,000 users.

Under these assumptions, Lightning is 180 times (17,900%) more efficient than basic Bitcoin.

Presumably, if around 30 million people are using Bitcoin via Lightning so that capacity is called into question, it will not be difficult to find consensus to double the block size to two megabytes and bring user capacity up to 105 million. The same goes for later increases to 200 million (4MB), 400 million (8MB), 800 million (16MB), 1.6 billion (32 MB), 3.2 billion (64MB), and all 7 billion living humans (133MB). In each case, all Lightning network participants get unlimited transactions to the other participants.

For basic Bitcoin to scale to just 2 transactions a day for 7 billion people would require 24-gigabyte blocks.<ref name="lightning_slides" />

=== Sidechains ===

==== Real quick, what are sidechains? ====

Block chains that are separate from Bitcoin’s block chain, but which allow you to receive and spend bitcoins using a two-way peg (2WP).<ref name="sidechains_paper">[https://www.blockstream.com/sidechains.pdf Sidechains paper], Adam Back et al., 22 October 2014</ref> (Although a sidechain can never be more secure than the Bitcoin block chain.<ref>[https://www.reddit.com/r/Bitcoin/comments/39r85g/sidechain_hate/cs5spbg Security limitations of pegged chains], Gregory Maxwell, 14 June 2015</ref>)

==== Are sidechains a scaling option? ====

No. Sidechains have the same fundamental scaling problems as Bitcoin does. Moving some transactions to sidechains simply moves some problems elsewhere on the network—the total difficulty of the problem remains the same.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008617.html Sidechains not a direct means for solving any of the scaling problems Bitcoin has], Pieter Wuille, 13 June 2015</ref>

==== But couldn’t I create a sidechain that had 100 GB blocks? ====

Certainly, sidechain code is open source<ref>[https://github.com/ElementsProject/elements Elements Project]</ref>—so you can create your own sidechain. But you’d still have the difficulty of finding people who are willing to validate 100 GB blocks with their own full nodes.

==== Do sidechains require a hard fork? ====

No. Federated sidechains, such as have already been implemented<ref>[https://github.com/ElementsProject/elements/tree/alpha Elements Alpha]</ref>, don’t require any changes to the Bitcoin consensus rules. Merged-mined sidechains, which have not been implemented yet, do require a backwards-compatible soft fork in order to transfer funds between Bitcoin and the sidechain.<ref name="sidechains_paper" />

== References ==
<references />

Scalability FAQ

2020-10-14T20:34:41Z

Midnightmagic:

Answers to commonly-asked questions and concerns about scaling Bitcoin, including “level 1” solutions such as increasing the block size and “level 2” solutions such as the proposed Lightning network.

== Background ==

Questions about how Bitcoin currently works (related to scaling) as well as questions about the technical terminology related to the scaling discussion.

=== What is the short history of the block size limit? ===

''Note: the software now called Bitcoin Core was previously simply called “Bitcoin”.<ref>[https://bitcoin.org/en/release/v0.9.0#rebranding-to-bitcoin-core Bitcoin Core 0.9.0 release notes], Bitcoin.org, 19 March 2014</ref>''

Bitcoin Core was initially released with a 32 MiB block size limit.<ref>[https://bitcointalk.org/index.php?topic=68121 Earliest known Bitcoin code], [https://github.com/trottier/original-bitcoin/blob/92ee8d9a994391d148733da77e2bbc2f4acc43cd/src/main.h#L17 src/main.h:17] and [https://github.com/trottier/original-bitcoin/blob/92ee8d9a994391d148733da77e2bbc2f4acc43cd/src/main.cpp#L1160 src/main.cpp:1160]</ref>

Around 15 July 2010, Satoshi Nakamoto changed Bitcoin Core’s mining code so that it wouldn’t create any blocks larger than 990,000 bytes.<ref>[https://github.com/bitcoin/bitcoin/commit/a30b56ebe76ffff9f9cc8a6667186179413c6349 Bitcoin Core commit a30b56e], Satoshi Nakamoto, 15 July 2010</ref>

Two months later on 7 September 2010, Nakamoto changed Bitcoin Core’s consensus rules to reject blocks larger than 1,000,000 bytes (1 megabyte) if their block height was higher than 79,400.<ref>[https://github.com/bitcoin/bitcoin/commit/8c9479c6bbbc38b897dc97de9d04e4d5a5a36730 Bitcoin Core commit 8c9479c], Satoshi Nakamoto, 7 September 2010</ref> (Block 79,400 was later produced on 12 September 2010.<ref>[https://explorer.blockstream.com/block/000000000021d821ec06be7173f413690bc5c4bc648dfa70b3b6763236f055b7 Block height 79400], dated 12 September 2010</ref>)

Neither the July nor the September commit message explains the reason for the limit, although the careful attempt to prevent a fork may indicate Nakamoto didn’t consider it an emergency.

Nakamoto’s subsequent warning not to run a blocksize increase patch which would have destructively forked the network said that '''if''' users needed to increase the blocksize, it '''could''' be accomplished with a planned hardfork at a future time<ref>[https://bitcointalk.org/index.php?topic=1347.msg15139#msg15139 Increasing the block size if needed], Satoshi Nakamoto, 3 October 2010</ref>, but he never specified which conditions might require one.

Statements by Nakamoto in the summer of 2010 indicate he believed Bitcoin could scale to block sizes far larger than 1 megabyte. For example, on 5 August 2010, he wrote that "[W]hatever size micropayments you need will eventually be practical. I think in 5 or 10 years, the bandwidth and storage will seem trivial" and "[microtransactions] can become more practical ... if I implement client-only mode and the number of network nodes consolidates into a smaller number of professional server farms" <ref>[https://bitcointalk.org/index.php?topic=532.msg6306#msg6306 the number of network nodes consolidates into a smaller number of professional server farms]</ref>. Satoshi's reasoning was likely based on his belief that SPV would be a primary scaling mechanism. It's since been discovered that SPV security requires strong fraud proofs and the fallback requires ''full node logic.'' <ref>[https://en.bitcoin.it/wiki/User:Gmaxwell/features#Proofs Greg Maxwell's outline of fraud proof logic] Greg Maxwell's wiki page, 22 March, 2013</ref><ref>[https://bitcointalk.org/index.php?topic=96644.msg1064601#msg1064601 Greg Maxwell's early post on fraud proofs] Greg Maxwell on fraud proofs, 30 July, 2012</ref>

In one of Nakamoto's final public messages, he wrote that "Bitcoin users might get increasingly tyrannical about limiting the size of the chain so it's easy for lots of users and small devices."<ref>[https://bitcointalk.org/index.php?topic=1790.msg28917#msg28917 BitDNS and Generalizing Bitcoin], Satoshi Nakamoto, 10 December 2010</ref> This statement suggests that Nakamoto was aware of the value of limiting the block size and that he correctly predicted it was an issue that Bitcoin users would be dealing with in the future---a future Nakamoto may have known would not include him. This was in the context of Satoshi attempting to redirect to a subchain non-Bitcoin uses like DNS data which used direct on-chain block space.

=== What is this Transactions Per Second (TPS) limit? ===

The current block size limit is 1,000,000 bytes (1 megabyte)<ref>[https://github.com/bitcoin/bitcoin/blob/41076aad0cbdfa4c4cf376e345114a5c29086f81/src/consensus/consensus.h#L10 <code>MAX_BLOCK_SIZE</code>], retrieved 2 July 2015</ref>, although a small amount of that space (such as the block header) is not available to store transactions.<ref>[https://bitcoin.org/en/developer-reference#serialized-blocks Block serialization description], Bitcoin.org Developer Reference</ref>

Bitcoin transactions vary in size depending on multiple factors, such as whether they’re spending single-signature inputs or a multiple signature inputs, and how many inputs and outputs they have.

The simple way to calculate the number of Transactions Per Second (TPS) Bitcoin can handle is to divide the block size limit by the expected average size of transactions, divided by the average number of seconds between blocks (600). For example, if you assume average transactions are 250 bytes,

<pre>6.6 TPS = 1,000,000 / 250 / 600</pre>

There seems to be general agreement that Bitcoin in 2015 can handle about 3 TPS with the current average size of transactions.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/007986.html Max TPS based on current average transaction size], Mike Hearn, 8 May 2015</ref><ref name="maxwell_not_proposing">[https://www.reddit.com/r/Bitcoin/comments/39yaod/bitcoinorg_position_on_hard_forks/cs7qz5c "No one proposing 3 TPS forever"], Gregory Maxwell, 15 June 2015</ref>

Both old estimates<ref>[[Scalability]], Bitcoin Wiki, retrieved 7 July
2015</ref> and newer estimates<ref name="garzik_bip" /> placed the pre-segwit
theoretical transaction speed at about 7 TPS.

=== What do devs mean by the scaling expressions O(1), O(n), O(n2), etc…? ===

[https://en.wikipedia.org/wiki/Big_O_notation Big O notation] is a shorthand used by computer scientists to describe how well a system scales. Such descriptions are rough approximations meant to help predict potential problems and evaluate potential solutions; they are not usually expected to fully capture all variables.

* '''O(1)''' means a system has roughly the same properties no matter how big it gets.
* '''O(n)''' means that a system scales linearly: doubling the number of things (users, transactions, etc.) doubles the amount of work.
* '''O(n2)''' means that a system scales quadratically : doubling (2x) the number of things quadruples (4x) the amount of work. Often written O(n^2) is places without convenient superscripts.
* Additional examples may be found in the [https://en.wikipedia.org/wiki/Big_O_notation#Orders_of_common_functions Wikipedia article]

The following subsections show cases where big O notation has been applied to the scaling Bitcoin transaction volume.

==== O(1) block propagation ====

Bitcoin Core relays unconfirmed transactions and then later reconstructs blocks when they are mined while avoiding redundant transaction propagation. The prior transaction double-relay redundancy was eliminated with the invention of a novel block propagation algorithm called Compact Blocks <ref>[https://bitcoincore.org/en/2016/06/07/compact-blocks-faq/ Compact Blocks] Compact Blocks, BIP0152</ref> to allow miners to propagate large blocks very quickly to active network nodes and also significantly reduced miners' need for powerful bandwidth. Miners use a network<ref name="block_relay_net">[http://bitcoinrelaynetwork.org/ Matt Corallo's block relay network]</ref> that is designed for high-bandwidth Wirehair-based<ref>[https://github.com/catid/wirehair Wirehair Github Repository] Wirehair</ref> which is slightly faster still than stock Bitcoin Core.

==== O(n2) network total validation resource requirements with decentralization level held constant ====

[[File:On2_scaling_illustrated.png|thumb|right|visualization of O(n2) scaling]]

While the validation effort required per full node simply grows in O(n), the combined validation effort of all nodes grows by O(n2) '''in the domain of resource consumption'', decentralization being held constant. For a single node, it takes twice as many resources to process the transactions of twice as many users, while for all nodes it takes a combined four times as many CPU resources to process the transactions of twice as many users assuming the number of full nodes increases in proportion to the number of users.

Each on-chain Bitcoin transaction needs to be processed by each full node. If we assume that a certain percentage of users run full nodes (''n'') and that each user creates a certain number of transactions on average (''n'' again), then the network’s total resource requirements are <code>n2 = n * n</code>. In short, this means that the aggregate cost of handling all transactions on-chain quadruples each time the number of users doubles.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009199.html Total system cost], Dr. Adam Back, 28 June 2015</ref> For example,

* Imagine a network starts with 100 users and 2 total nodes (a 2% ratio).

* The network doubles in users to 200. The number of nodes also doubles to 4 (maintaining a 2% ratio of decentralized low-trust security). However, double the number of users means double the number of transactions, and each node needs to process ''every'' transaction---so each node now does double work with its bandwidth and its CPU. With double the number of nodes and double the amount of work per node, total work increases by four times.

* The network doubles again: 400 users, 8 nodes (still 2% of total), and 4 times the original workload per node for a total of 16 times as much aggregate work as the original.

* Another doubling: 800 users, 16 nodes (still 2%), and 8 times the original workload per node for a total of 64 times aggregate work as the original.

* Another doubling: 1,600 users—sixteen times the original---with 32 nodes (still 2%), and 16 times the original workload per node. The aggregate total work done by nodes is 256 times higher than it was originally.

===== Criticisms =====

Emphasis on the total validation resource requirements is suggested by some individuals to be misleading, as they claim it obfuscates the growth of the supporting base of full nodes that the total validation resource effort is split amongst. The validation resource effort made by each individual full node increases at O(n), and critics say this is the only pertinent fact with respect to scaling. Some critics also point out that the O(n2) network total validation resource requirements claim is assuming decentralization must be held constant as the network scales, and that this is not a founding principle of Bitcoin. Of course, as quoted above, Satoshi knew that decentralization would be a critical value of the safety of the system in the first place by demonstrating he could foresee multiple paths for the future of Bitcoin.

=== What’s the difference between on-chain and off-chain transactions? ===

On-chain Bitcoin transactions are those that appear in the Bitcoin block chain. Off-chain transactions are those that transfer ownership of bitcoins without putting a transaction on the block chain.

Common and proposed off-chain transactions include:

* '''Exchange transactions:''' when you buy or sell bitcoins, the exchange tracks ownership in a database without putting data in the block chain. Only when you deposit or withdraw bitcoins does the transaction appear on the block chain.
* '''Web wallet internal payments:''' many web wallets allow users of the service to pay other users of the same service using off-chain payments. For example, when one Coinbase user pays another Coinbase user. '''WARNING: Web wallets are extremely unsafe and many users have had funds stolen from them worth many hundreds of millions of dollars in today's exchange rates.'''
* '''Tipping services:''' most tipping services todayvuse off-chain transactions for everything except deposits and withdrawals from their services.
* '''Payment channels:''' channels are started using one on-chain transaction and ended using a second on-chain transaction.<ref>[https://bitcoin.org/en/developer-guide#micropayment-channel Micropayment channels], Bitcoin.org Developer Guide</ref> In between can be an essentially unlimited number of off-chain transactions as small as a single satoshi (1/100,000,000th of a bitcoin). Payment channels include those that were baked into the protocol at release as well as proposed hub-and-spoke channels and the more advanced [http://lightning.network/ Lightning network].

The vast majority of all bitcoin-denominated payments today are made off-chain.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008844.html Pure off-chain is a weak form of layer 2], Dr. Adam Back, 19 June 2015</ref>

=== What is a fee market? ===

When you create a Bitcoin transaction, you have the option to pay a [[transaction fee]]. If your software is flexible, you can pay anything from zero fees (a free transaction) to 100% of the value of the transaction (spend-to-fees). This fee is comparable to a tip. The higher it is, the bigger the incentive of the miners to incorporate your transaction into the next block.

When miners assemble a block, they are free to include whatever transactions they wish. They usually include as many as possible up to the maximum block size and then prioritize the transactions that pay the most fees per kilobyte of data.<ref name="fee_pri">[https://bitcointalk.org/index.php?topic=95837.0 Fee prioritization patch], Gavin Andresen, 26 July 2012</ref> This usually results in higher-fee transactions confirming before lower-fee transactions. If blocks become full on a regular basis, users who pay a fee that's too small will have to wait a longer and longer time for their transactions to confirm. At this point, a demand-driven fee market will arise where transactions that pay higher fees get confirmed significantly faster than transactions that pay low fees.<ref name="todd_coinwallet">[https://gist.github.com/petertodd/8e87c782bdf342ef18fb Comments on the CoinWallet.eu tx-flood stress-test], Peter Todd, 22 June 2015</ref><ref name="garzik_bip" />

In a competitive market, prices are driven by supply and demand and the emerging equilibrium price asymptotically approaches marginal costs over time. However, the current version of segwit-enabled Bitcoin limits the supply to 4 MW (4 million weight units) per block, allowing only demand to adjust. It turns out that a fee market can stabilize as long as there is a block size limit.<ref>[https://medium.com/@bergealex4/bitcoin-is-unstable-without-the-block-size-size-limit-70db07070a54 Bitcoin is unstable without a block size limit], Alex B., 24 Oct 2016</ref> Simply allowing individual miners to include as many transactions as they want is problematic due to the externalities<ref name="exernality">[https://en.wikipedia.org/wiki/Externality Definition of externality], Wikipedia, 26 January 2016</ref> of including additional blocks and explained further in section [[#Should miners be allowed to decide the block size?|'should miners be allowed to decide the block size?']] .

=== The naive way to scale Bitcoin ===

If Bitcoin decentralization is abandoned, whatever is left could scale limitlessly as a plain database-backed ledger. Mining uses enormous amounts of electricity to provide a secure, verifiable decentralized ledger and full nodes use an enormous amount of bandwidth and CPU time keeping miners honest.

To wit, if users instead decided to hand authority over to someone they trusted, mining and keeping miners honest wouldn’t be necessary. This is how Visa, MasterCard, PayPal, and the rest of the centralized payment systems works—users trust them, and they have no special difficulty scaling to [[scalability|millions of transactions an hour]]. It’s comparatively energy-efficient; it isn’t decentralized, and thus isn't efficient to the ''purpose that Bitcoin was designed to accommodate.''

=== What is a hard fork, and how does it differ from other types of forks? ===

The word fork is badly overloaded in Bitcoin development. The following terms are used, for example:

* '''[[hardfork|Hard fork]]:''' a change to the system which is not backwards compatible. Everyone needs to upgrade or things will go wrong.
* '''[[softfork|Soft fork]]:''' a change to the system which is backwards compatible as long as a majority of miners enforce it. Full nodes that don’t upgrade potentially but not necessarily have reduced security.
* '''Chain fork:''' when there are two are more blocks at the same height on a block chain. This typically happens a few times a week by accident, but it can also indicate more severe problems.
* '''[https://en.wikipedia.org/wiki/Fork_%28software_development%29 Software fork]:''' using the code from an open source project to create a different project.
* '''[https://help.github.com/articles/fork-a-repo/ Git/GitHub fork]:''' a way for developers to write and test new features before contributing them to a project.

(There are other types of software-related forks, but they don’t tend to cause as much confusion.)

=== What are the block size soft limits? ===

Bitcoin Core has historically come pre-configured to limit blocks it mines to certain sizes.<ref name="fee_pri" /> These “limits” aren’t restrictions placed on miners by other miners or nodes, but rather configuration options that help miners produce reasonably-sized blocks.

Miners can change their soft limit size (up to 4 MW) using <code>-blockmaxweight=<size></code>

Default soft limits at various times:

* '''July 2012:''' <code>-blockmaxsize</code> option created and set to default 250 KB soft limit<ref>[https://github.com/bitcoin/bitcoin/commit/c555400ca134991e39d5e3a565fcd2215abe56f6 Bitcoin Core commit c555400], Gavin Andresen, 12 July 2012</ref>
* '''November 2013:''' Raised to 750KB<ref>[https://github.com/bitcoin/bitcoin/commit/ad898b40aaf06c1cc7ac12e953805720fc9217c0 Bitcoin Core commit ad898b40], Gavin Andresen, 27 November 2013</ref>
* '''June 2015:''' Raise to 1 MB suggested<ref>[https://github.com/bitcoin/bitcoin/pull/6231 Bitcoin Core pull #6231], Chris Wheeler, 4 June 2015</ref>
* '''August 2017:''' Segwit activates at block 481824<ref>[https://explorer.blockstream.com/block/0000000000000000001c8018d9cb3b742ef25114f27563e3fc4a1902167f9893 Block 481824] August 23, 2017</ref>

== General Block Size Increase Theory ==

==== Why are some people in favour of keeping the block size conservative forever? ====

It is commonly claimed<ref name="garzik_bip" /><ref>[https://epicenterbitcoin.com/podcast/082/ Epicenter Bitcoin podcast #82], Mike Hearn (interviewed), 8 June 2015</ref> that there are people opposed to ever raising the maximum block size limit, but no Bitcoin developers have suggested a permanent blocksize.<ref name="maxwell_not_proposing" />

All developers support raising the maximum size at some point<ref>[https://www.reddit.com/r/Bitcoin/comments/39kqzs/how_about_a_softfork_optin_blocksize_increase/cs5hj8l Nothing magic about 1MB], Dr. Adam Back, 13 June 2015</ref><ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008328.html Regarding size-independent new block propagation], Pieter Wuille, 28 May 2015</ref>—they just disagree about whether now is the correct time.

==== Should miners be allowed to decide the block size? ====

A block may include as little as a single transaction, so miners can always restrict block size. Letting miners choose the maximum block size is more problematic for several reasons:

# '''Miners profit, others pay the cost:''' bigger blocks earn miners more fees, but technically miners can successfully mine without storing block data almost at all.<ref>[https://github.com/bitcoin/bitcoin/pull/5863 Bitcoin Core pull #5863 adding pruning functionality], Suhas Daftuar et al., 6 March 2015</ref> Some miners will SPV mine optimistically on other miners' blocks without even validating anyting. Other users who want full validation security, or who provide services to lightweight wallets, pay the costs of downloading and storing those larger blocks.
# '''Bigger miners can afford more bandwidth:''' each miner needs to download every transaction that they want to include in blocks,<ref name="maxwell_correcting_assumptions" /> which means that they all need high-speed connections. However, a miner with 8.3% of total hash rate can take that cost out of the about 300 BTC they make a day, while a miner with only 0.7% of total hash rate has to take that cost out of only 25 BTC a day. This means bigger miners may logically choose to make bigger blocks even though it may further centralize mining.
# '''Centralized hardware production:''' only a few companies in the world produce efficient mining equipment, and many of them have historically chosen to stop selling to the public.<ref>[http://blogs.wsj.com/venturecapital/2014/09/05/for-kncminer-time-to-forget-selling-bitcoin-machines-to-at-home-miners/ KnCMiner to stop selling to home miners], Wall Street Journal, Yuliya Chernova, 5 September 2014</ref> This prevents ordinary Bitcoin users from participating in the process even if they were willing to pay for mining equipment.
# '''Voting by hash rate favours larger miners:''' voting based on hash rate allows the current hash rate majority (or super-majority) to enforce conditions on the minority. This is similar to a lobby of large businesses being able to get laws passed that may hurt smaller businesses.<ref>[https://www.reddit.com/r/Bitcoin/comments/39kzyt/draft_bip_100_soft_fork_block_size_increase/cs5gvak Miners choosing the block size limit is ill-advised], Meni Rosenfeld, 13 June 2015</ref> This is less of an issue now that miner-signalled activation has been abandoned.
# '''Miners do not care about users:''' this was demonstrated during the [[July 2015 Forks]] where even after miners lost over $50,000 USD in income from mining invalid chains, and even after they were told that long forks harm users, they continued to mine invalid blocks.<ref>[https://bitcointalk.org/index.php?topic=700411.msg11790734#msg11790734 Intention to continue SPV mining], Wang Chun, 4 July 2015</ref>

However, there are also possible justifications for letting miners choose the block size:

# '''Authenticated participants:''' miners are active participants in Bitcoin, and they can prove it by adding data to the blocks they create.<ref>[https://bitcoin.org/en/developer-reference#term-coinbase-field Coinbase field], Bitcoin.org Developer Reference</ref> It is much harder to prove people on Reddit, BitcoinTalk, and elsewhere are real people with an active stake in Bitcoin.
# '''Bigger blocks may cost smaller miners:''' small miners and poorly-connected miners are at a disadvantage if larger blocks are produced<ref name="wuille_centralization" />, and even large and well-connected miners may find that large blocks reduce their profit percentage if the cost of bandwidth rises too high or their stale rate increases.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008355.html F2Pool block size concerns], Chun Wang, 29 May 2015</ref>

==== How could a block size increase affect user security? ====

Bitcoin’s security is highly dependent on the number of active users who protect their bitcoins with a full node like Bitcoin Core. The more active users of full nodes, the harder it is for miners to trick users into accepting fake bitcoins or other frauds.<ref>[https://medium.com/@lopp/bitcoin-nodes-how-many-is-enough-9b8e8f6fd2cf Bitcoin nodes: how many is enough?], Jameson Lopp, 7 June 2015</ref>

Full nodes need to download and verify every block, and most nodes also store blocks plus relay transactions, blocks, and filtered blocks to other users on the network. The bigger blocks become, the more difficult it becomes to do all this, so it is expected that bigger blocks will both reduce the number of users who currently run full nodes and suppress the number of users who decide to start running a full node later.<ref>[https://www.reddit.com/r/Bitcoin/comments/3bae2d/amir_taaki_on_raising_the_block_size_a_lot_of/cslcgmw Block size increases-only will create problems], Dr. Adam Back, 28 June 2015</ref>

In addition, full blocks may increase mining centralization<ref name="wuille_centralization" /> at a time when mining is already so centralized that it makes it easy to reverse transactions which have been confirmed multiple times.<ref>[http://bitcoin.stackexchange.com/questions/32562/when-to-worry-about-1-confirmation-payments/32564#32564 When to worry about one-confirmation payments], David A. Harding, 17 November 2014</ref>

==== How could larger blocks affect proof-of-work (POW) security? ====

Proof of work security is dependent on how much money miners spend on mining equipment. However, to effectively mine blocks, miners also need to spend money on bandwidth to receive new transactions and blocks created by other miners; CPUs to validate received transactions and blocks; and bandwidth to upload new blocks. These additional costs don’t directly contribute to POW security.<ref name="maxwell_correcting_assumptions">[https://www.reddit.com/r/Bitcoin/comments/39tgno/letting_miners_vote_on_the_maximum_block_size_is/cs6rek5 Correcting wrong assumptions about mining], Gregory Maxwell, 15 June 2015</ref>

As block sizes increase, the amount of bandwidth and CPU required also increases. If block sizes increase faster than the costs of bandwidth and CPU decrease, miners will have less money for POW security relative to the gross income they earn.

In addition, larger blocks have a higher risk of becoming stale (orphaned)<ref name="rusty_dsl" />, which directly correlates to lost POW security. For example, if the network average stale rate is 10%, then 10% of POW performed isn't protecting transactions on the block chain.

=== What happens if blocks aren't big enough to include all pending transactions? ===

This is already often the case, so we know that miners will simply queue transactions. The transactions eligible for block inclusion that pay the highest fee per kiloweight will be confirmed earlier than transactions that pay comparatively lower fees.<ref name="fee_pri" />

What happens from there is debated:

* BitcoinJ lead developer Mike Hearn believed in 2015 there would be “crashing nodes, a swelling transaction backlog, a sudden spike in double spending, [and] skyrocketing fees.”<ref>[https://medium.com/@octskyward/crash-landing-f5cc19908e32 Crash Landing], Mike Hearn, 7 May 2015</ref> Clearly this didn't happen, as of late 2020.
* Bitcoin Foundation chief scientist Gavin Andresen believed in 2015 that the “average transaction fee paid will rise, people or applications unwilling or unable to pay the rising fees will stop submitting transactions, [and] people and businesses will shelve plans to use Bitcoin, stunting growth and adoption.” <ref>[https://github.com/bitcoin/bitcoin/pull/6341 Bitcoin Core pull #6341], Gavin Andresen, 26 June 2015</ref> Clearly, this didn't happen either, as of late 2020.
* Bitcoin Core developer Pieter Wuille replied in 2015 to Andresen’s comment above: “Is it fair to summarize this as ‘Some use cases won’t fit any more, people will decide to no longer use the blockchain for these purposes, and the fees will adapt.’? I think that is already happening […] I don’t think we should be afraid of this change or try to stop it.” <ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009098.html The need for larger blocks], Pieter Wuille, 26 June 2015</ref>

== Segregated Witness ==

Segregated Witness, a block size increase proposal implemented as a soft-fork and which increased the block size to 4 megabytes (actually 4 mega-weight units but strictly-speaking that is contained within 4 megabytes maximum) was adopted as the Bitcoin blocksize increase in August 2017 in block 481824<ref>[https://explorer.blockstream.com/block/0000000000000000001c8018d9cb3b742ef25114f27563e3fc4a1902167f9893 Block 481824] Block 481824</ref>. It was most favoured by the user community and the Bitcoin developers, in spite of significant political pressure against it by signalling miners and attackers. Segwit was eventually forced into activation by James Hilliard's BIP0091<ref>[https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki BIP 0091], James Hilliard, May 22, 2017.</ref>

== Specific Scaling Proposals (for historical interest) ==

=== Andresen-Hearn Block Size Increase Proposals ===

Questions about the series of related proposals by Gavin Andresen and Mike Hearn to use a hard fork to raise the maximum block size, thereby allowing miners to include more on-chain transactions. As of July 2015, the current focus was [https://github.com/bitcoin/bips/pull/163 BIP101].

==== What was the major advantage of this proposal? ====

''Bitcoin can support many more users.'' Assuming earliest possible adoption, 250 bytes per on-chain transaction, 144 blocks per day, and 2 transaction a day per user, Bitcoin can support about,

* 288,000 users in 2015
* 2,304,000 users in 2016 (800% increase)
* 4,608,000 in 2018 (1,600%)
* 9,216,000 in 2020 (3,200%)
* 18,432,000 in 2022 (6,400%)
* 36,864,000 in 2024 (12,800%)
* 73,728,000 in 2026 (25,600%)
* 147,456,000 in 2028 (51,200%)
* 294,912,000 in 2030 (102,400%)
* 589,824,000 in 2032 (204,800%)
* 1,179,648,000 in 2034 (409,600%
* 2,359,296,000 in 2036 (819,200%)

==== What is the major disadvantage of this proposal? ====

''The total cost of remaining decentralized will be high.'' Assuming earliest possible adoption and that the ratio of total users to full node operators remains the same as today, the total estimated amount of work necessary to maintain the decentralized system under the [[#O.28n2.29_network_total_validation_resource_requirements|O(2) scaling model]] will be,

* 100% of today’s work in 2015
* 6,400% in 2016
* 25,600% in 2018
* 102,400% in 2020
* 409,600% in 2022
* 1,638,400% in 2024
* 6,553,600% in 2026
* 26,214,400% in 2028
* 104,857,600% in 2030
* 419,430,400% in 2032
* 1,677,721,600% in 2034
* 6,710,886,400% in 2036

For example, if the total amount spent on running full nodes today (not counting mining) is $100 thousand per year, the estimated cost for the same level of decentralization in 2036 will be $6.7 trillion per year if validation costs stay the same. (They'll certainly go down, but algorithmic and hardware improvements probably won't eliminate an approximate 6,710,886,400% cost increase.)

==== What are the dangers of the proposed hard fork? ====

Under the then-current current proposal, 75% of miners must indicate that they agree to accept blocks up to 8 MB in size.<ref name="bip101">[https://github.com/bitcoin/bips/pull/163 BIP101], Gavin Andresen, 24 June 2016</ref> After the change goes into effect, if any miner creates a block larger than 1 MB, all nodes which have not upgraded yet will reject the block.<ref>[https://bitcoin.org/en/developer-guide#consensus-rule-changes Consensus rule changes], Bitcoin.org Developer Guide</ref>

If all full nodes have upgraded, or very close to all nodes, there should be no practical effect. If a significant number of full nodes have not upgraded, they will continue using a different block chain than the upgraded users, with the following consequences:

* Bitcoins received from before the fork can be spent twice, once on both sides of the fork. This creates a high double spend risk.
* Bitcoins received after the fork are only guaranteed to be spendable on the side of the fork they were received on. This means some users will have to lose money to restore Bitcoin to a single chain.

Users of hosted wallets (Coinbase, BlockChain.info, etc.) will use whatever block chain their host chooses. Users of lightweight P2P SPV wallets will use the [[Thin Client Security|longest chain they know of]], which may not be the actual longest chain if they only connect to nodes on the shorter chain. Users of non-P2P SPV wallets, like Electrum, will use whatever chain is used by the server they connect to.

If a bad hard fork like this happens, it will likely cause large-scale confusion and make Bitcoin very hard to use until the situation is resolved.

==== What is the deployment schedule for BIP 101? ====

* The patch needs to be accepted into Bitcoin Core, Bitcoin XT, or both.
* If accepted into Bitcoin Core, miners using that software will need to upgrade (this probably requires a new released version of Bitcoin Core). If accepted only into Bitcoin XT, miners will need to switch to using XT.
* After 75% of miners have upgraded, 8MB blocks will become allowed at the the latest of (1) 11 January 2016 or (2) two weeks after the 75% upgrade threshold.<ref name="bip101" />
* After the effective date has passed, any miner may create a block larger than 8MB. When a miner does this, upgraded full nodes will accept that block and non-upgraded full nodes will reject it, forking the network.<ref name="bip101" /> See [[#What_are_the_dangers_of_the_proposed_hard_fork.3F|hard fork dangers]] for what his might mean.

==== Will miners go straight from 1 MB blocks to 8 MB blocks? ====

That would be highly unlikely. Uploading an 8 MB block currently takes significantly more time than uploading a 1 MB block<ref name="rusty_dsl">[http://rusty.ozlabs.org/?p=509 Mining on a home DSL connection test results], Rusty Russell, 19 June 2015</ref>, even with the roughly 25x reduction in size available from use of Matt Corallo’s block relay network.<ref name="block_relay_net" />

The longer it takes to upload a block, the higher the risk it will become a stale block—meaning the miner who created it will not receive the block subsidy or transaction fees (currently about 25 BTC per block).

However, if technology like Invertible Bloom Lookup Tables (IBLTs) is deployed and found to work as expected<ref name="iblt">[https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2 O(1) block propagation], Gavin Andresen, 8 August 2014</ref>, or if mining [[#What_is_the_most_efficient_way_to_scale_Bitcoin.3F|centralizes further]], adding additional transactions may not have a significant enough cost to discourage miners from creating full blocks. In that case, blocks will be filled as soon as there are enough people wanting to make transactions paying the default relay fee<ref>[https://github.com/bitcoin/bitcoin/pull/3305 Bitcoin Core pull #3305 dropping default fees], Mike Hearn, 22 November 2013</ref> of 0.00001000 BTC/kilobyte.

==== What tests have been performed related to this proposal? ====

* '''20MB block processing''' (Gavin Andresen) “if we increased the maximum block size to 20 megabytes tomorrow, and every single miner decided to start creating 20MB blocks and there was a sudden increase in the number of transactions on the network to fill up those blocks… the 0.10.0 version of [Bitcoin Core] would run just fine.”<ref>[http://gavintech.blogspot.com/2015/01/twenty-megabytes-testing-results.html Twenty megabyte block testing], Gavin Andresen, 20 January 2015</ref> (ellipses in original)
* '''Mining & relay simulation''' (Gavin Andresen) “if blocks take 20 seconds to propagate, a network with a miner that has 30% of the hashing power will get 30.3% of the blocks.”<ref>[http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners Are bigger blocks better for bigger miners?], Gavin Andresen, 22 May 2015</ref>
* '''Mining on a home DSL connection''' (Rusty Russell) “Using the rough formula of 1-exp(-t/600), I would expect orphan rates of 10.5% generating 1MB blocks, and 56.6% with 8MB blocks; that’s a huge cut in expected profits.”<ref name="rusty_dsl" />
* '''Mining centralization pressure''' (Pieter Wuille) “[This] does very clearly show the effects of larger blocks on centralization pressure of the system.”<ref name="wuille_centralization">[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008581.html Mining centralization pressure from non-uniform propagation speed], Pieter Wuille, 12 June 2015</ref>

=== Garzik Miner Block Size Voting Proposal (AKA BIP100) ===

''Note, BIP 100 is the marketing name for this proposal. No BIP number
has yet been publicly requested, and the number assigned is unlikely to
be 100.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-May/005756.html
Prenumbered BIP naming], Gregory Maxwell, 12 May 2014</ref>''

Questions related to Jeff Garzik's proposal<ref name="garzik_bip">[http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf Draft BIP: decentralized economic policy], Jeff Garzik, 12 June 2015 (revised 15 June 2015)</ref> to allow miners to vote on raising and lowering the maximum block size.

==== What does this proposal do? ====

# It creates a one-time hard fork that does not automatically change the maximum block size.

# It allows miners to vote to increase or decrease the maximum block size within the range of 1MB to 32MB. These changes are neither hard forks nor soft forks, but simply rules that all nodes should know about after the initial hard fork.

==== Does it reduce the risk of a hard fork? ====

Hard forks are most dangerous when they're done without strong
consensus.<ref name="garzik_bip" /><ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008779.html Consensus changes are not about making a change to the software],
Pieter Wuille, 18 June 2015</ref>

If Garzik's proposal gains strong consensus, it will be as safe as possible
for a hard fork and it will allow increasing the block size up to 32 MB
without any additional risk of a fork.

==== Why is it limited to 32 megabytes? ====

According to the draft BIP, "the 32 MB hard fork is largely coincidental -- a whole network upgrade at 32 MB was likely needed anyway."

=== Lightning Network ===

Questions related to using the proposed [http://lightning.network/ Lightning network] as a way to scale the number of users Bitcoin can support.

==== How does transaction security differ from that of Bitcoin? ====

Transactions on the proposed Lightning network use Bitcoin transactions exclusively to transfer bitcoins<ref name="russell_lightning1">[http://rusty.ozlabs.org/?p=450 Lightning Networks: Part I], Rusty Russell, 30 March 2015</ref>, and so the same security as regular Bitcoin transactions is provided when both a Lightning hub and client are cooperating.

When a Lightning hub or client refuses to cooperate with the other (maybe because they accidentally went offline), the other party can still receive their full 100% bitcoin balance by closing the payment channel—but they must first wait for a defined amount of time mutually chosen by both the hub and client.<ref>[http://rusty.ozlabs.org/?p=462 Lightning Networks: Part II], Rusty Russell, 1 April 2015</ref>

If one party waits too long to close the payment channel, the other party may be able to steal bitcoins. However, it is possible to delegate the task of closing the channel in an emergency to an unlimited number of hubs around the Internet, so closing the channel on time should be easy.<ref name="russell_lightning4">[http://rusty.ozlabs.org/?p=477 Lightning Networks: Part IV], Rusty Russell, 8 April 2015</ref>

In summary, provided that payment channels are closed on time, the worst that can happen to users is that they may have to wait a few weeks for a channel to fully close before spending the bitcoins they received from it. Their security is otherwise the same as with regular Bitcoin.

For Lightning hubs, security is slightly worse in the sense that they need to keep a potentially-large amount of funds in a hot wallet<ref name="lightning_paper">[http://lightning.network/lightning-network-paper-DRAFT-0.5.pdf Lightning Network (Draft 0.5)], Section 6.3: Coin Theft via Hacking, Joseph Poon and Thaddeus Dryja</ref>, so they can’t take advantage of the anti-hacking protection offered by cold wallets. Otherwise, Lightning hubs have the same security as clients.

==== When will Lightning be ready for use? ====

Lightning requires a basic test implementation (work underway<ref>[https://lists.blockstream.com/pipermail/lightning-dev/2015-June/000018.html Lightning first steps], Rusty Russell, 13 June 2015</ref>), several soft-fork changes to the Bitcoin protocol (work underway<ref>[https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65: CheckLockTimeVerify], Peter Todd, 1 October 2014</ref><ref>[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68: Consensus-enforced transaction replacement], Mark Friedenbach, 28 May 2015</ref>, and wallets need to be updated to support the Lightning network protocol.<ref name="russell_lightning4" />

Dr. Adam Back has said, "I expect we can get something running inside a year."<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009242.html Reply to Andresen regarding Lightning], Dr. Adam Back, 28 June 2015</ref>

==== Doesn’t Lightning require bigger blocks anyway? ====

Lightning is block-size neutral. It requires one on-chain transaction to open a channel between a hub and a client, and one on-chain transaction to close a channel.<ref name="russell_lightning1" /> In between it can support an unlimited number of transactions between anyone on the Lightning network.<ref name="lightning_paper" />

Using the numbers from the Lightning presentation<ref name="lightning_slides">[http://lightning.network/lightning-network.pdf Lightning presentation], Joseph Poon, 23 February 2015</ref>, if people open and close a plausible two channels a year, Lightning can support about 52 million users with the current one-megabyte limit—and each user can make an unlimited number of transactions. Currently, assuming people make an average of only two Bitcoin transactions a day, basic Bitcoin can support only 288,000 users.

Under these assumptions, Lightning is 180 times (17,900%) more efficient than basic Bitcoin.

Presumably, if around 30 million people are using Bitcoin via Lightning so that capacity is called into question, it will not be difficult to find consensus to double the block size to two megabytes and bring user capacity up to 105 million. The same goes for later increases to 200 million (4MB), 400 million (8MB), 800 million (16MB), 1.6 billion (32 MB), 3.2 billion (64MB), and all 7 billion living humans (133MB). In each case, all Lightning network participants get unlimited transactions to the other participants.

For basic Bitcoin to scale to just 2 transactions a day for 7 billion people would require 24-gigabyte blocks.<ref name="lightning_slides" />

=== Sidechains ===

==== Real quick, what are sidechains? ====

Block chains that are separate from Bitcoin’s block chain, but which allow you to receive and spend bitcoins using a two-way peg (2WP).<ref name="sidechains_paper">[https://www.blockstream.com/sidechains.pdf Sidechains paper], Adam Back et al., 22 October 2014</ref> (Although a sidechain can never be more secure than the Bitcoin block chain.<ref>[https://www.reddit.com/r/Bitcoin/comments/39r85g/sidechain_hate/cs5spbg Security limitations of pegged chains], Gregory Maxwell, 14 June 2015</ref>)

==== Are sidechains a scaling option? ====

No. Sidechains have the same fundamental scaling problems as Bitcoin does. Moving some transactions to sidechains simply moves some problems elsewhere on the network—the total difficulty of the problem remains the same.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008617.html Sidechains not a direct means for solving any of the scaling problems Bitcoin has], Pieter Wuille, 13 June 2015</ref>

==== But couldn’t I create a sidechain that had 100 GB blocks? ====

Certainly, sidechain code is open source<ref>[https://github.com/ElementsProject/elements Elements Project]</ref>—so you can create your own sidechain. But you’d still have the difficulty of finding people who are willing to validate 100 GB blocks with their own full nodes.

==== Do sidechains require a hard fork? ====

No. Federated sidechains, such as have already been implemented<ref>[https://github.com/ElementsProject/elements/tree/alpha Elements Alpha]</ref>, don’t require any changes to the Bitcoin consensus rules. Merged-mined sidechains, which have not been implemented yet, do require a backwards-compatible soft fork in order to transfer funds between Bitcoin and the sidechain.<ref name="sidechains_paper" />

== References ==
<references />

Scalability FAQ

2020-10-14T20:33:25Z

Midnightmagic:

Answers to commonly-asked questions and concerns about scaling Bitcoin, including “level 1” solutions such as increasing the block size and “level 2” solutions such as the proposed Lightning network.

== Background ==

Questions about how Bitcoin currently works (related to scaling) as well as questions about the technical terminology related to the scaling discussion.

=== What is the short history of the block size limit? ===

''Note: the software now called Bitcoin Core was previously simply called “Bitcoin”.<ref>[https://bitcoin.org/en/release/v0.9.0#rebranding-to-bitcoin-core Bitcoin Core 0.9.0 release notes], Bitcoin.org, 19 March 2014</ref>''

Bitcoin Core was initially released with a 32 MiB block size limit.<ref>[https://bitcointalk.org/index.php?topic=68121 Earliest known Bitcoin code], [https://github.com/trottier/original-bitcoin/blob/92ee8d9a994391d148733da77e2bbc2f4acc43cd/src/main.h#L17 src/main.h:17] and [https://github.com/trottier/original-bitcoin/blob/92ee8d9a994391d148733da77e2bbc2f4acc43cd/src/main.cpp#L1160 src/main.cpp:1160]</ref>

Around 15 July 2010, Satoshi Nakamoto changed Bitcoin Core’s mining code so that it wouldn’t create any blocks larger than 990,000 bytes.<ref>[https://github.com/bitcoin/bitcoin/commit/a30b56ebe76ffff9f9cc8a6667186179413c6349 Bitcoin Core commit a30b56e], Satoshi Nakamoto, 15 July 2010</ref>

Two months later on 7 September 2010, Nakamoto changed Bitcoin Core’s consensus rules to reject blocks larger than 1,000,000 bytes (1 megabyte) if their block height was higher than 79,400.<ref>[https://github.com/bitcoin/bitcoin/commit/8c9479c6bbbc38b897dc97de9d04e4d5a5a36730 Bitcoin Core commit 8c9479c], Satoshi Nakamoto, 7 September 2010</ref> (Block 79,400 was later produced on 12 September 2010.<ref>[https://explorer.blockstream.com/block/000000000021d821ec06be7173f413690bc5c4bc648dfa70b3b6763236f055b7 Block height 79400], dated 12 September 2010</ref>)

Neither the July nor the September commit message explains the reason for the limit, although the careful attempt to prevent a fork may indicate Nakamoto didn’t consider it an emergency.

Nakamoto’s subsequent warning not to run a blocksize increase patch which would have destructively forked the network said that '''if''' users needed to increase the blocksize, it '''could''' be accomplished with a planned hardfork at a future time<ref>[https://bitcointalk.org/index.php?topic=1347.msg15139#msg15139 Increasing the block size if needed], Satoshi Nakamoto, 3 October 2010</ref>, but he never specified which conditions might require one.

Statements by Nakamoto in the summer of 2010 indicate he believed Bitcoin could scale to block sizes far larger than 1 megabyte. For example, on 5 August 2010, he wrote that "[W]hatever size micropayments you need will eventually be practical. I think in 5 or 10 years, the bandwidth and storage will seem trivial" and "[microtransactions] can become more practical ... if I implement client-only mode and the number of network nodes consolidates into a smaller number of professional server farms" <ref>[https://bitcointalk.org/index.php?topic=532.msg6306#msg6306 the number of network nodes consolidates into a smaller number of professional server farms]</ref>. Satoshi's reasoning was likely based on his belief that SPV would be a primary scaling mechanism. It's since been discovered that SPV security requires strong fraud proofs and the fallback requires ''full node logic.'' <ref>[https://en.bitcoin.it/wiki/User:Gmaxwell/features#Proofs Greg Maxwell's outline of fraud proof logic] Greg Maxwell's wiki page, 22 March, 2013</ref><ref>[https://bitcointalk.org/index.php?topic=96644.msg1064601#msg1064601 Greg Maxwell's early post on fraud proofs] Greg Maxwell on fraud proofs, 30 July, 2012</ref>

In one of Nakamoto's final public messages, he wrote that "Bitcoin users might get increasingly tyrannical about limiting the size of the chain so it's easy for lots of users and small devices."<ref>[https://bitcointalk.org/index.php?topic=1790.msg28917#msg28917 BitDNS and Generalizing Bitcoin], Satoshi Nakamoto, 10 December 2010</ref> This statement suggests that Nakamoto was aware of the value of limiting the block size and that he correctly predicted it was an issue that Bitcoin users would be dealing with in the future---a future Nakamoto may have known would not include him. This was in the context of Satoshi attempting to redirect to a subchain non-Bitcoin uses like DNS data which used direct on-chain block space.

=== What is this Transactions Per Second (TPS) limit? ===

The current block size limit is 1,000,000 bytes (1 megabyte)<ref>[https://github.com/bitcoin/bitcoin/blob/41076aad0cbdfa4c4cf376e345114a5c29086f81/src/consensus/consensus.h#L10 <code>MAX_BLOCK_SIZE</code>], retrieved 2 July 2015</ref>, although a small amount of that space (such as the block header) is not available to store transactions.<ref>[https://bitcoin.org/en/developer-reference#serialized-blocks Block serialization description], Bitcoin.org Developer Reference</ref>

Bitcoin transactions vary in size depending on multiple factors, such as whether they’re spending single-signature inputs or a multiple signature inputs, and how many inputs and outputs they have.

The simple way to calculate the number of Transactions Per Second (TPS) Bitcoin can handle is to divide the block size limit by the expected average size of transactions, divided by the average number of seconds between blocks (600). For example, if you assume average transactions are 250 bytes,

<pre>6.6 TPS = 1,000,000 / 250 / 600</pre>

There seems to be general agreement that Bitcoin in 2015 can handle about 3 TPS with the current average size of transactions.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/007986.html Max TPS based on current average transaction size], Mike Hearn, 8 May 2015</ref><ref name="maxwell_not_proposing">[https://www.reddit.com/r/Bitcoin/comments/39yaod/bitcoinorg_position_on_hard_forks/cs7qz5c "No one proposing 3 TPS forever"], Gregory Maxwell, 15 June 2015</ref>

Both old estimates<ref>[[Scalability]], Bitcoin Wiki, retrieved 7 July
2015</ref> and newer estimates<ref name="garzik_bip" /> placed the pre-segwit
theoretical transaction speed at about 7 TPS.

=== What do devs mean by the scaling expressions O(1), O(n), O(n2), etc…? ===

[https://en.wikipedia.org/wiki/Big_O_notation Big O notation] is a shorthand used by computer scientists to describe how well a system scales. Such descriptions are rough approximations meant to help predict potential problems and evaluate potential solutions; they are not usually expected to fully capture all variables.

* '''O(1)''' means a system has roughly the same properties no matter how big it gets.
* '''O(n)''' means that a system scales linearly: doubling the number of things (users, transactions, etc.) doubles the amount of work.
* '''O(n2)''' means that a system scales quadratically : doubling (2x) the number of things quadruples (4x) the amount of work. Often written O(n^2) is places without convenient superscripts.
* Additional examples may be found in the [https://en.wikipedia.org/wiki/Big_O_notation#Orders_of_common_functions Wikipedia article]

The following subsections show cases where big O notation has been applied to the scaling Bitcoin transaction volume.

==== O(1) block propagation ====

Bitcoin Core relays unconfirmed transactions and then later reconstructs blocks when they are mined while avoiding redundant transaction propagation. The prior transaction double-relay redundancy was eliminated with the invention of a novel block propagation algorithm called Compact Blocks <ref>[https://bitcoincore.org/en/2016/06/07/compact-blocks-faq/ Compact Blocks] Compact Blocks, BIP0152</ref> to allow miners to propagate large blocks very quickly to active network nodes and also significantly reduced miners' need for powerful bandwidth. Miners use a network<ref name="block_relay_net">[http://bitcoinrelaynetwork.org/ Matt Corallo's block relay network]</ref> that is designed for high-bandwidth Wirehair-based<ref>[https://github.com/catid/wirehair Wirehair Github Repository] Wirehair</ref> which is slightly faster still than stock Bitcoin Core.

==== O(n2) network total validation resource requirements with decentralization level held constant ====

[[File:On2_scaling_illustrated.png|thumb|right|visualization of O(n2) scaling]]

While the validation effort required per full node simply grows in O(n), the combined validation effort of all nodes grows by O(n2) '''in the domain of resource consumption'', decentralization being held constant. For a single node, it takes twice as many resources to process the transactions of twice as many users, while for all nodes it takes a combined four times as many CPU resources to process the transactions of twice as many users assuming the number of full nodes increases in proportion to the number of users.

Each on-chain Bitcoin transaction needs to be processed by each full node. If we assume that a certain percentage of users run full nodes (''n'') and that each user creates a certain number of transactions on average (''n'' again), then the network’s total resource requirements are <code>n2 = n * n</code>. In short, this means that the aggregate cost of handling all transactions on-chain quadruples each time the number of users doubles.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009199.html Total system cost], Dr. Adam Back, 28 June 2015</ref> For example,

* Imagine a network starts with 100 users and 2 total nodes (a 2% ratio).

* The network doubles in users to 200. The number of nodes also doubles to 4 (maintaining a 2% ratio of decentralized low-trust security). However, double the number of users means double the number of transactions, and each node needs to process ''every'' transaction---so each node now does double work with its bandwidth and its CPU. With double the number of nodes and double the amount of work per node, total work increases by four times.

* The network doubles again: 400 users, 8 nodes (still 2% of total), and 4 times the original workload per node for a total of 16 times as much aggregate work as the original.

* Another doubling: 800 users, 16 nodes (still 2%), and 8 times the original workload per node for a total of 64 times aggregate work as the original.

* Another doubling: 1,600 users—sixteen times the original---with 32 nodes (still 2%), and 16 times the original workload per node. The aggregate total work done by nodes is 256 times higher than it was originally.

===== Criticisms =====

Emphasis on the total validation resource requirements is suggested by some individuals to be misleading, as they claim it obfuscates the growth of the supporting base of full nodes that the total validation resource effort is split amongst. The validation resource effort made by each individual full node increases at O(n), and critics say this is the only pertinent fact with respect to scaling. Some critics also point out that the O(n2) network total validation resource requirements claim is assuming decentralization must be held constant as the network scales, and that this is not a founding principle of Bitcoin. Of course, as quoted above, Satoshi knew that decentralization would be a critical value of the safety of the system in the first place by demonstrating he could foresee multiple paths for the future of Bitcoin.

=== What’s the difference between on-chain and off-chain transactions? ===

On-chain Bitcoin transactions are those that appear in the Bitcoin block chain. Off-chain transactions are those that transfer ownership of bitcoins without putting a transaction on the block chain.

Common and proposed off-chain transactions include:

* '''Exchange transactions:''' when you buy or sell bitcoins, the exchange tracks ownership in a database without putting data in the block chain. Only when you deposit or withdraw bitcoins does the transaction appear on the block chain.
* '''Web wallet internal payments:''' many web wallets allow users of the service to pay other users of the same service using off-chain payments. For example, when one Coinbase user pays another Coinbase user. '''WARNING: Web wallets are extremely unsafe and many users have had funds stolen from them worth many hundreds of millions of dollars in today's exchange rates.'''
* '''Tipping services:''' most tipping services todayvuse off-chain transactions for everything except deposits and withdrawals from their services.
* '''Payment channels:''' channels are started using one on-chain transaction and ended using a second on-chain transaction.<ref>[https://bitcoin.org/en/developer-guide#micropayment-channel Micropayment channels], Bitcoin.org Developer Guide</ref> In between can be an essentially unlimited number of off-chain transactions as small as a single satoshi (1/100,000,000th of a bitcoin). Payment channels include those that were baked into the protocol at release as well as proposed hub-and-spoke channels and the more advanced [http://lightning.network/ Lightning network].

The vast majority of all bitcoin-denominated payments today are made off-chain.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008844.html Pure off-chain is a weak form of layer 2], Dr. Adam Back, 19 June 2015</ref>

=== What is a fee market? ===

When you create a Bitcoin transaction, you have the option to pay a [[transaction fee]]. If your software is flexible, you can pay anything from zero fees (a free transaction) to 100% of the value of the transaction (spend-to-fees). This fee is comparable to a tip. The higher it is, the bigger the incentive of the miners to incorporate your transaction into the next block.

When miners assemble a block, they are free to include whatever transactions they wish. They usually include as many as possible up to the maximum block size and then prioritize the transactions that pay the most fees per kilobyte of data.<ref name="fee_pri">[https://bitcointalk.org/index.php?topic=95837.0 Fee prioritization patch], Gavin Andresen, 26 July 2012</ref> This usually results in higher-fee transactions confirming before lower-fee transactions. If blocks become full on a regular basis, users who pay a fee that's too small will have to wait a longer and longer time for their transactions to confirm. At this point, a demand-driven fee market will arise where transactions that pay higher fees get confirmed significantly faster than transactions that pay low fees.<ref name="todd_coinwallet">[https://gist.github.com/petertodd/8e87c782bdf342ef18fb Comments on the CoinWallet.eu tx-flood stress-test], Peter Todd, 22 June 2015</ref><ref name="garzik_bip" />

In a competitive market, prices are driven by supply and demand and the emerging equilibrium price asymptotically approaches marginal costs over time. However, the current version of segwit-enabled Bitcoin limits the supply to 4 MW (4 million weight units) per block, allowing only demand to adjust. It turns out that a fee market can stabilize as long as there is a block size limit.<ref>[https://medium.com/@bergealex4/bitcoin-is-unstable-without-the-block-size-size-limit-70db07070a54 Bitcoin is unstable without a block size limit], Alex B., 24 Oct 2016</ref> Simply allowing individual miners to include as many transactions as they want is problematic due to the externalities<ref name="exernality">[https://en.wikipedia.org/wiki/Externality Definition of externality], Wikipedia, 26 January 2016</ref> of including additional blocks and explained further in section [[#Should miners be allowed to decide the block size?|'should miners be allowed to decide the block size?']] .

=== The naive way to scale Bitcoin ===

If Bitcoin decentralization is abandoned, whatever is left could scale limitlessly as a plain database-backed ledger. Mining uses enormous amounts of electricity to provide a secure, verifiable decentralized ledger and full nodes use an enormous amount of bandwidth and CPU time keeping miners honest.

To wit, if users instead decided to hand authority over to someone they trusted, mining and keeping miners honest wouldn’t be necessary. This is how Visa, MasterCard, PayPal, and the rest of the centralized payment systems works—users trust them, and they have no special difficulty scaling to [[scalability|millions of transactions an hour]]. It’s comparatively energy-efficient; it isn’t decentralized, and thus isn't efficient to the ''purpose that Bitcoin was designed to accommodate.''

=== What is a hard fork, and how does it differ from other types of forks? ===

The word fork is badly overloaded in Bitcoin development. The following terms are used, for example:

* '''[[hardfork|Hard fork]]:''' a change to the system which is not backwards compatible. Everyone needs to upgrade or things will go wrong.
* '''[[softfork|Soft fork]]:''' a change to the system which is backwards compatible as long as a majority of miners enforce it. Full nodes that don’t upgrade potentially but not necessarily have reduced security.
* '''Chain fork:''' when there are two are more blocks at the same height on a block chain. This typically happens a few times a week by accident, but it can also indicate more severe problems.
* '''[https://en.wikipedia.org/wiki/Fork_%28software_development%29 Software fork]:''' using the code from an open source project to create a different project.
* '''[https://help.github.com/articles/fork-a-repo/ Git/GitHub fork]:''' a way for developers to write and test new features before contributing them to a project.

(There are other types of software-related forks, but they don’t tend to cause as much confusion.)

=== What are the block size soft limits? ===

Bitcoin Core has historically come pre-configured to limit blocks it mines to certain sizes.<ref name="fee_pri" /> These “limits” aren’t restrictions placed on miners by other miners or nodes, but rather configuration options that help miners produce reasonably-sized blocks.

Miners can change their soft limit size (up to 4 MW) using <code>-blockmaxweight=<size></code>

Default soft limits at various times:

* '''July 2012:''' <code>-blockmaxsize</code> option created and set to default 250 KB soft limit<ref>[https://github.com/bitcoin/bitcoin/commit/c555400ca134991e39d5e3a565fcd2215abe56f6 Bitcoin Core commit c555400], Gavin Andresen, 12 July 2012</ref>
* '''November 2013:''' Raised to 750KB<ref>[https://github.com/bitcoin/bitcoin/commit/ad898b40aaf06c1cc7ac12e953805720fc9217c0 Bitcoin Core commit ad898b40], Gavin Andresen, 27 November 2013</ref>
* '''June 2015:''' Raise to 1 MB suggested<ref>[https://github.com/bitcoin/bitcoin/pull/6231 Bitcoin Core pull #6231], Chris Wheeler, 4 June 2015</ref>
* '''August 2017:''' Segwit activates at block 481824<ref>[https://explorer.blockstream.com/block/0000000000000000001c8018d9cb3b742ef25114f27563e3fc4a1902167f9893 Block 481824] August 23, 2017</ref>

== General Block Size Increase Theory ==

==== Why are some people in favour of keeping the block size conservative forever? ====

It is commonly claimed<ref name="garzik_bip" /><ref>[https://epicenterbitcoin.com/podcast/082/ Epicenter Bitcoin podcast #82], Mike Hearn (interviewed), 8 June 2015</ref> that there are people opposed to ever raising the maximum block size limit, but no Bitcoin developers have suggested a permanent blocksize.<ref name="maxwell_not_proposing" />

All developers support raising the maximum size at some point<ref>[https://www.reddit.com/r/Bitcoin/comments/39kqzs/how_about_a_softfork_optin_blocksize_increase/cs5hj8l Nothing magic about 1MB], Dr. Adam Back, 13 June 2015</ref><ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008328.html Regarding size-independent new block propagation], Pieter Wuille, 28 May 2015</ref>—they just disagree about whether now is the correct time.

==== Should miners be allowed to decide the block size? ====

A block may include as little as a single transaction, so miners can always restrict block size. Letting miners choose the maximum block size is more problematic for several reasons:

# '''Miners profit, others pay the cost:''' bigger blocks earn miners more fees, but technically miners can successfully mine without storing block data almost at all.<ref>[https://github.com/bitcoin/bitcoin/pull/5863 Bitcoin Core pull #5863 adding pruning functionality], Suhas Daftuar et al., 6 March 2015</ref> Some miners will SPV mine optimistically on other miners' blocks without even validating anyting. Other users who want full validation security, or who provide services to lightweight wallets, pay the costs of downloading and storing those larger blocks.
# '''Bigger miners can afford more bandwidth:''' each miner needs to download every transaction that they want to include in blocks,<ref name="maxwell_correcting_assumptions" /> which means that they all need high-speed connections. However, a miner with 8.3% of total hash rate can take that cost out of the about 300 BTC they make a day, while a miner with only 0.7% of total hash rate has to take that cost out of only 25 BTC a day. This means bigger miners may logically choose to make bigger blocks even though it may further centralize mining.
# '''Centralized hardware production:''' only a few companies in the world produce efficient mining equipment, and many of them have historically chosen to stop selling to the public.<ref>[http://blogs.wsj.com/venturecapital/2014/09/05/for-kncminer-time-to-forget-selling-bitcoin-machines-to-at-home-miners/ KnCMiner to stop selling to home miners], Wall Street Journal, Yuliya Chernova, 5 September 2014</ref> This prevents ordinary Bitcoin users from participating in the process even if they were willing to pay for mining equipment.
# '''Voting by hash rate favours larger miners:''' voting based on hash rate allows the current hash rate majority (or super-majority) to enforce conditions on the minority. This is similar to a lobby of large businesses being able to get laws passed that may hurt smaller businesses.<ref>[https://www.reddit.com/r/Bitcoin/comments/39kzyt/draft_bip_100_soft_fork_block_size_increase/cs5gvak Miners choosing the block size limit is ill-advised], Meni Rosenfeld, 13 June 2015</ref> This is less of an issue now that miner-signalled activation has been abandoned.
# '''Miners do not care about users:''' this was demonstrated during the [[July 2015 Forks]] where even after miners lost over $50,000 USD in income from mining invalid chains, and even after they were told that long forks harm users, they continued to mine invalid blocks.<ref>[https://bitcointalk.org/index.php?topic=700411.msg11790734#msg11790734 Intention to continue SPV mining], Wang Chun, 4 July 2015</ref>

However, there are also possible justifications for letting miners choose the block size:

# '''Authenticated participants:''' miners are active participants in Bitcoin, and they can prove it by adding data to the blocks they create.<ref>[https://bitcoin.org/en/developer-reference#term-coinbase-field Coinbase field], Bitcoin.org Developer Reference</ref> It is much harder to prove people on Reddit, BitcoinTalk, and elsewhere are real people with an active stake in Bitcoin.
# '''Bigger blocks may cost smaller miners:''' small miners and poorly-connected miners are at a disadvantage if larger blocks are produced<ref name="wuille_centralization" />, and even large and well-connected miners may find that large blocks reduce their profit percentage if the cost of bandwidth rises too high or their stale rate increases.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008355.html F2Pool block size concerns], Chun Wang, 29 May 2015</ref>

==== How could a block size increase affect user security? ====

Bitcoin’s security is highly dependent on the number of active users who protect their bitcoins with a full node like Bitcoin Core. The more active users of full nodes, the harder it is for miners to trick users into accepting fake bitcoins or other frauds.<ref>[https://medium.com/@lopp/bitcoin-nodes-how-many-is-enough-9b8e8f6fd2cf Bitcoin nodes: how many is enough?], Jameson Lopp, 7 June 2015</ref>

Full nodes need to download and verify every block, and most nodes also store blocks plus relay transactions, blocks, and filtered blocks to other users on the network. The bigger blocks become, the more difficult it becomes to do all this, so it is expected that bigger blocks will both reduce the number of users who currently run full nodes and suppress the number of users who decide to start running a full node later.<ref>[https://www.reddit.com/r/Bitcoin/comments/3bae2d/amir_taaki_on_raising_the_block_size_a_lot_of/cslcgmw Block size increases-only will create problems], Dr. Adam Back, 28 June 2015</ref>

In addition, full blocks may increase mining centralization<ref name="wuille_centralization" /> at a time when mining is already so centralized that it makes it easy to reverse transactions which have been confirmed multiple times.<ref>[http://bitcoin.stackexchange.com/questions/32562/when-to-worry-about-1-confirmation-payments/32564#32564 When to worry about one-confirmation payments], David A. Harding, 17 November 2014</ref>

==== How could larger blocks affect proof-of-work (POW) security? ====

Proof of work security is dependent on how much money miners spend on mining equipment. However, to effectively mine blocks, miners also need to spend money on bandwidth to receive new transactions and blocks created by other miners; CPUs to validate received transactions and blocks; and bandwidth to upload new blocks. These additional costs don’t directly contribute to POW security.<ref name="maxwell_correcting_assumptions">[https://www.reddit.com/r/Bitcoin/comments/39tgno/letting_miners_vote_on_the_maximum_block_size_is/cs6rek5 Correcting wrong assumptions about mining], Gregory Maxwell, 15 June 2015</ref>

As block sizes increase, the amount of bandwidth and CPU required also increases. If block sizes increase faster than the costs of bandwidth and CPU decrease, miners will have less money for POW security relative to the gross income they earn.

In addition, larger blocks have a higher risk of becoming stale (orphaned)<ref name="rusty_dsl" />, which directly correlates to lost POW security. For example, if the network average stale rate is 10%, then 10% of POW performed isn't protecting transactions on the block chain.

=== What happens if blocks aren't big enough to include all pending transactions? ===

This is already often the case, so we know that miners will simply queue transactions. The transactions eligible for block inclusion that pay the highest fee per kiloweight will be confirmed earlier than transactions that pay comparatively lower fees.<ref name="fee_pri" />

What happens from there is debated:

* BitcoinJ lead developer Mike Hearn believed in 2015 there would be “crashing nodes, a swelling transaction backlog, a sudden spike in double spending, [and] skyrocketing fees.”<ref>[https://medium.com/@octskyward/crash-landing-f5cc19908e32 Crash Landing], Mike Hearn, 7 May 2015</ref> Clearly this didn't happen, as of late 2020.
* Bitcoin Foundation chief scientist Gavin Andresen believed in 2015 that the “average transaction fee paid will rise, people or applications unwilling or unable to pay the rising fees will stop submitting transactions, [and] people and businesses will shelve plans to use Bitcoin, stunting growth and adoption.” <ref>[https://github.com/bitcoin/bitcoin/pull/6341 Bitcoin Core pull #6341], Gavin Andresen, 26 June 2015</ref> Clearly, this didn't happen either, as of late 2020.
* Bitcoin Core developer Pieter Wuille replied in 2015 to Andresen’s comment above: “Is it fair to summarize this as ‘Some use cases won’t fit any more, people will decide to no longer use the blockchain for these purposes, and the fees will adapt.’? I think that is already happening […] I don’t think we should be afraid of this change or try to stop it.” <ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009098.html The need for larger blocks], Pieter Wuille, 26 June 2015</ref>

== Segregated Witness ==

Segregated Witness, a block size increase proposal implemented as a soft-fork and which increased the block size to 4 megabytes (actually 4 mega-weight units but strictly-speaking that is contained within 4 megabytes maximum) was adopted as the Bitcoin blocksize increase in August 2017 in block 481824<ref>[https://explorer.blockstream.com/block/0000000000000000001c8018d9cb3b742ef25114f27563e3fc4a1902167f9893 Block 481824] Block 481824</ref> which was most favoured by the user community, in spite of significant political pressure against it by signalling miners and attackers. Segwit was eventually forced into activation by James Hilliard's BIP0091<ref>[https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki BIP 0091], James Hilliard, May 22, 2017.</ref>

== Specific Scaling Proposals (for historical interest) ==

=== Andresen-Hearn Block Size Increase Proposals ===

Questions about the series of related proposals by Gavin Andresen and Mike Hearn to use a hard fork to raise the maximum block size, thereby allowing miners to include more on-chain transactions. As of July 2015, the current focus was [https://github.com/bitcoin/bips/pull/163 BIP101].

==== What was the major advantage of this proposal? ====

''Bitcoin can support many more users.'' Assuming earliest possible adoption, 250 bytes per on-chain transaction, 144 blocks per day, and 2 transaction a day per user, Bitcoin can support about,

* 288,000 users in 2015
* 2,304,000 users in 2016 (800% increase)
* 4,608,000 in 2018 (1,600%)
* 9,216,000 in 2020 (3,200%)
* 18,432,000 in 2022 (6,400%)
* 36,864,000 in 2024 (12,800%)
* 73,728,000 in 2026 (25,600%)
* 147,456,000 in 2028 (51,200%)
* 294,912,000 in 2030 (102,400%)
* 589,824,000 in 2032 (204,800%)
* 1,179,648,000 in 2034 (409,600%
* 2,359,296,000 in 2036 (819,200%)

==== What is the major disadvantage of this proposal? ====

''The total cost of remaining decentralized will be high.'' Assuming earliest possible adoption and that the ratio of total users to full node operators remains the same as today, the total estimated amount of work necessary to maintain the decentralized system under the [[#O.28n2.29_network_total_validation_resource_requirements|O(2) scaling model]] will be,

* 100% of today’s work in 2015
* 6,400% in 2016
* 25,600% in 2018
* 102,400% in 2020
* 409,600% in 2022
* 1,638,400% in 2024
* 6,553,600% in 2026
* 26,214,400% in 2028
* 104,857,600% in 2030
* 419,430,400% in 2032
* 1,677,721,600% in 2034
* 6,710,886,400% in 2036

For example, if the total amount spent on running full nodes today (not counting mining) is $100 thousand per year, the estimated cost for the same level of decentralization in 2036 will be $6.7 trillion per year if validation costs stay the same. (They'll certainly go down, but algorithmic and hardware improvements probably won't eliminate an approximate 6,710,886,400% cost increase.)

==== What are the dangers of the proposed hard fork? ====

Under the then-current current proposal, 75% of miners must indicate that they agree to accept blocks up to 8 MB in size.<ref name="bip101">[https://github.com/bitcoin/bips/pull/163 BIP101], Gavin Andresen, 24 June 2016</ref> After the change goes into effect, if any miner creates a block larger than 1 MB, all nodes which have not upgraded yet will reject the block.<ref>[https://bitcoin.org/en/developer-guide#consensus-rule-changes Consensus rule changes], Bitcoin.org Developer Guide</ref>

If all full nodes have upgraded, or very close to all nodes, there should be no practical effect. If a significant number of full nodes have not upgraded, they will continue using a different block chain than the upgraded users, with the following consequences:

* Bitcoins received from before the fork can be spent twice, once on both sides of the fork. This creates a high double spend risk.
* Bitcoins received after the fork are only guaranteed to be spendable on the side of the fork they were received on. This means some users will have to lose money to restore Bitcoin to a single chain.

Users of hosted wallets (Coinbase, BlockChain.info, etc.) will use whatever block chain their host chooses. Users of lightweight P2P SPV wallets will use the [[Thin Client Security|longest chain they know of]], which may not be the actual longest chain if they only connect to nodes on the shorter chain. Users of non-P2P SPV wallets, like Electrum, will use whatever chain is used by the server they connect to.

If a bad hard fork like this happens, it will likely cause large-scale confusion and make Bitcoin very hard to use until the situation is resolved.

==== What is the deployment schedule for BIP 101? ====

* The patch needs to be accepted into Bitcoin Core, Bitcoin XT, or both.
* If accepted into Bitcoin Core, miners using that software will need to upgrade (this probably requires a new released version of Bitcoin Core). If accepted only into Bitcoin XT, miners will need to switch to using XT.
* After 75% of miners have upgraded, 8MB blocks will become allowed at the the latest of (1) 11 January 2016 or (2) two weeks after the 75% upgrade threshold.<ref name="bip101" />
* After the effective date has passed, any miner may create a block larger than 8MB. When a miner does this, upgraded full nodes will accept that block and non-upgraded full nodes will reject it, forking the network.<ref name="bip101" /> See [[#What_are_the_dangers_of_the_proposed_hard_fork.3F|hard fork dangers]] for what his might mean.

==== Will miners go straight from 1 MB blocks to 8 MB blocks? ====

That would be highly unlikely. Uploading an 8 MB block currently takes significantly more time than uploading a 1 MB block<ref name="rusty_dsl">[http://rusty.ozlabs.org/?p=509 Mining on a home DSL connection test results], Rusty Russell, 19 June 2015</ref>, even with the roughly 25x reduction in size available from use of Matt Corallo’s block relay network.<ref name="block_relay_net" />

The longer it takes to upload a block, the higher the risk it will become a stale block—meaning the miner who created it will not receive the block subsidy or transaction fees (currently about 25 BTC per block).

However, if technology like Invertible Bloom Lookup Tables (IBLTs) is deployed and found to work as expected<ref name="iblt">[https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2 O(1) block propagation], Gavin Andresen, 8 August 2014</ref>, or if mining [[#What_is_the_most_efficient_way_to_scale_Bitcoin.3F|centralizes further]], adding additional transactions may not have a significant enough cost to discourage miners from creating full blocks. In that case, blocks will be filled as soon as there are enough people wanting to make transactions paying the default relay fee<ref>[https://github.com/bitcoin/bitcoin/pull/3305 Bitcoin Core pull #3305 dropping default fees], Mike Hearn, 22 November 2013</ref> of 0.00001000 BTC/kilobyte.

==== What tests have been performed related to this proposal? ====

* '''20MB block processing''' (Gavin Andresen) “if we increased the maximum block size to 20 megabytes tomorrow, and every single miner decided to start creating 20MB blocks and there was a sudden increase in the number of transactions on the network to fill up those blocks… the 0.10.0 version of [Bitcoin Core] would run just fine.”<ref>[http://gavintech.blogspot.com/2015/01/twenty-megabytes-testing-results.html Twenty megabyte block testing], Gavin Andresen, 20 January 2015</ref> (ellipses in original)
* '''Mining & relay simulation''' (Gavin Andresen) “if blocks take 20 seconds to propagate, a network with a miner that has 30% of the hashing power will get 30.3% of the blocks.”<ref>[http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners Are bigger blocks better for bigger miners?], Gavin Andresen, 22 May 2015</ref>
* '''Mining on a home DSL connection''' (Rusty Russell) “Using the rough formula of 1-exp(-t/600), I would expect orphan rates of 10.5% generating 1MB blocks, and 56.6% with 8MB blocks; that’s a huge cut in expected profits.”<ref name="rusty_dsl" />
* '''Mining centralization pressure''' (Pieter Wuille) “[This] does very clearly show the effects of larger blocks on centralization pressure of the system.”<ref name="wuille_centralization">[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008581.html Mining centralization pressure from non-uniform propagation speed], Pieter Wuille, 12 June 2015</ref>

=== Garzik Miner Block Size Voting Proposal (AKA BIP100) ===

''Note, BIP 100 is the marketing name for this proposal. No BIP number
has yet been publicly requested, and the number assigned is unlikely to
be 100.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-May/005756.html
Prenumbered BIP naming], Gregory Maxwell, 12 May 2014</ref>''

Questions related to Jeff Garzik's proposal<ref name="garzik_bip">[http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf Draft BIP: decentralized economic policy], Jeff Garzik, 12 June 2015 (revised 15 June 2015)</ref> to allow miners to vote on raising and lowering the maximum block size.

==== What does this proposal do? ====

# It creates a one-time hard fork that does not automatically change the maximum block size.

# It allows miners to vote to increase or decrease the maximum block size within the range of 1MB to 32MB. These changes are neither hard forks nor soft forks, but simply rules that all nodes should know about after the initial hard fork.

==== Does it reduce the risk of a hard fork? ====

Hard forks are most dangerous when they're done without strong
consensus.<ref name="garzik_bip" /><ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008779.html Consensus changes are not about making a change to the software],
Pieter Wuille, 18 June 2015</ref>

If Garzik's proposal gains strong consensus, it will be as safe as possible
for a hard fork and it will allow increasing the block size up to 32 MB
without any additional risk of a fork.

==== Why is it limited to 32 megabytes? ====

According to the draft BIP, "the 32 MB hard fork is largely coincidental -- a whole network upgrade at 32 MB was likely needed anyway."

=== Lightning Network ===

Questions related to using the proposed [http://lightning.network/ Lightning network] as a way to scale the number of users Bitcoin can support.

==== How does transaction security differ from that of Bitcoin? ====

Transactions on the proposed Lightning network use Bitcoin transactions exclusively to transfer bitcoins<ref name="russell_lightning1">[http://rusty.ozlabs.org/?p=450 Lightning Networks: Part I], Rusty Russell, 30 March 2015</ref>, and so the same security as regular Bitcoin transactions is provided when both a Lightning hub and client are cooperating.

When a Lightning hub or client refuses to cooperate with the other (maybe because they accidentally went offline), the other party can still receive their full 100% bitcoin balance by closing the payment channel—but they must first wait for a defined amount of time mutually chosen by both the hub and client.<ref>[http://rusty.ozlabs.org/?p=462 Lightning Networks: Part II], Rusty Russell, 1 April 2015</ref>

If one party waits too long to close the payment channel, the other party may be able to steal bitcoins. However, it is possible to delegate the task of closing the channel in an emergency to an unlimited number of hubs around the Internet, so closing the channel on time should be easy.<ref name="russell_lightning4">[http://rusty.ozlabs.org/?p=477 Lightning Networks: Part IV], Rusty Russell, 8 April 2015</ref>

In summary, provided that payment channels are closed on time, the worst that can happen to users is that they may have to wait a few weeks for a channel to fully close before spending the bitcoins they received from it. Their security is otherwise the same as with regular Bitcoin.

For Lightning hubs, security is slightly worse in the sense that they need to keep a potentially-large amount of funds in a hot wallet<ref name="lightning_paper">[http://lightning.network/lightning-network-paper-DRAFT-0.5.pdf Lightning Network (Draft 0.5)], Section 6.3: Coin Theft via Hacking, Joseph Poon and Thaddeus Dryja</ref>, so they can’t take advantage of the anti-hacking protection offered by cold wallets. Otherwise, Lightning hubs have the same security as clients.

==== When will Lightning be ready for use? ====

Lightning requires a basic test implementation (work underway<ref>[https://lists.blockstream.com/pipermail/lightning-dev/2015-June/000018.html Lightning first steps], Rusty Russell, 13 June 2015</ref>), several soft-fork changes to the Bitcoin protocol (work underway<ref>[https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65: CheckLockTimeVerify], Peter Todd, 1 October 2014</ref><ref>[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68: Consensus-enforced transaction replacement], Mark Friedenbach, 28 May 2015</ref>, and wallets need to be updated to support the Lightning network protocol.<ref name="russell_lightning4" />

Dr. Adam Back has said, "I expect we can get something running inside a year."<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009242.html Reply to Andresen regarding Lightning], Dr. Adam Back, 28 June 2015</ref>

==== Doesn’t Lightning require bigger blocks anyway? ====

Lightning is block-size neutral. It requires one on-chain transaction to open a channel between a hub and a client, and one on-chain transaction to close a channel.<ref name="russell_lightning1" /> In between it can support an unlimited number of transactions between anyone on the Lightning network.<ref name="lightning_paper" />

Using the numbers from the Lightning presentation<ref name="lightning_slides">[http://lightning.network/lightning-network.pdf Lightning presentation], Joseph Poon, 23 February 2015</ref>, if people open and close a plausible two channels a year, Lightning can support about 52 million users with the current one-megabyte limit—and each user can make an unlimited number of transactions. Currently, assuming people make an average of only two Bitcoin transactions a day, basic Bitcoin can support only 288,000 users.

Under these assumptions, Lightning is 180 times (17,900%) more efficient than basic Bitcoin.

Presumably, if around 30 million people are using Bitcoin via Lightning so that capacity is called into question, it will not be difficult to find consensus to double the block size to two megabytes and bring user capacity up to 105 million. The same goes for later increases to 200 million (4MB), 400 million (8MB), 800 million (16MB), 1.6 billion (32 MB), 3.2 billion (64MB), and all 7 billion living humans (133MB). In each case, all Lightning network participants get unlimited transactions to the other participants.

For basic Bitcoin to scale to just 2 transactions a day for 7 billion people would require 24-gigabyte blocks.<ref name="lightning_slides" />

=== Sidechains ===

==== Real quick, what are sidechains? ====

Block chains that are separate from Bitcoin’s block chain, but which allow you to receive and spend bitcoins using a two-way peg (2WP).<ref name="sidechains_paper">[https://www.blockstream.com/sidechains.pdf Sidechains paper], Adam Back et al., 22 October 2014</ref> (Although a sidechain can never be more secure than the Bitcoin block chain.<ref>[https://www.reddit.com/r/Bitcoin/comments/39r85g/sidechain_hate/cs5spbg Security limitations of pegged chains], Gregory Maxwell, 14 June 2015</ref>)

==== Are sidechains a scaling option? ====

No. Sidechains have the same fundamental scaling problems as Bitcoin does. Moving some transactions to sidechains simply moves some problems elsewhere on the network—the total difficulty of the problem remains the same.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008617.html Sidechains not a direct means for solving any of the scaling problems Bitcoin has], Pieter Wuille, 13 June 2015</ref>

==== But couldn’t I create a sidechain that had 100 GB blocks? ====

Certainly, sidechain code is open source<ref>[https://github.com/ElementsProject/elements Elements Project]</ref>—so you can create your own sidechain. But you’d still have the difficulty of finding people who are willing to validate 100 GB blocks with their own full nodes.

==== Do sidechains require a hard fork? ====

No. Federated sidechains, such as have already been implemented<ref>[https://github.com/ElementsProject/elements/tree/alpha Elements Alpha]</ref>, don’t require any changes to the Bitcoin consensus rules. Merged-mined sidechains, which have not been implemented yet, do require a backwards-compatible soft fork in order to transfer funds between Bitcoin and the sidechain.<ref name="sidechains_paper" />

== References ==
<references />

Scalability FAQ

2020-10-14T20:32:24Z

Midnightmagic: and segwit was activated. the end.

Answers to commonly-asked questions and concerns about scaling Bitcoin, including “level 1” solutions such as increasing the block size and “level 2” solutions such as the proposed Lightning network.

== Background ==

Questions about how Bitcoin currently works (related to scaling) as well as questions about the technical terminology related to the scaling discussion.

=== What is the short history of the block size limit? ===

''Note: the software now called Bitcoin Core was previously simply called “Bitcoin”.<ref>[https://bitcoin.org/en/release/v0.9.0#rebranding-to-bitcoin-core Bitcoin Core 0.9.0 release notes], Bitcoin.org, 19 March 2014</ref>''

Bitcoin Core was initially released with a 32 MiB block size limit.<ref>[https://bitcointalk.org/index.php?topic=68121 Earliest known Bitcoin code], [https://github.com/trottier/original-bitcoin/blob/92ee8d9a994391d148733da77e2bbc2f4acc43cd/src/main.h#L17 src/main.h:17] and [https://github.com/trottier/original-bitcoin/blob/92ee8d9a994391d148733da77e2bbc2f4acc43cd/src/main.cpp#L1160 src/main.cpp:1160]</ref>

Around 15 July 2010, Satoshi Nakamoto changed Bitcoin Core’s mining code so that it wouldn’t create any blocks larger than 990,000 bytes.<ref>[https://github.com/bitcoin/bitcoin/commit/a30b56ebe76ffff9f9cc8a6667186179413c6349 Bitcoin Core commit a30b56e], Satoshi Nakamoto, 15 July 2010</ref>

Two months later on 7 September 2010, Nakamoto changed Bitcoin Core’s consensus rules to reject blocks larger than 1,000,000 bytes (1 megabyte) if their block height was higher than 79,400.<ref>[https://github.com/bitcoin/bitcoin/commit/8c9479c6bbbc38b897dc97de9d04e4d5a5a36730 Bitcoin Core commit 8c9479c], Satoshi Nakamoto, 7 September 2010</ref> (Block 79,400 was later produced on 12 September 2010.<ref>[https://explorer.blockstream.com/block/000000000021d821ec06be7173f413690bc5c4bc648dfa70b3b6763236f055b7 Block height 79400], dated 12 September 2010</ref>)

Neither the July nor the September commit message explains the reason for the limit, although the careful attempt to prevent a fork may indicate Nakamoto didn’t consider it an emergency.

Nakamoto’s subsequent warning not to run a blocksize increase patch which would have destructively forked the network said that '''if''' users needed to increase the blocksize, it '''could''' be accomplished with a planned hardfork at a future time<ref>[https://bitcointalk.org/index.php?topic=1347.msg15139#msg15139 Increasing the block size if needed], Satoshi Nakamoto, 3 October 2010</ref>, but he never specified which conditions might require one.

Statements by Nakamoto in the summer of 2010 indicate he believed Bitcoin could scale to block sizes far larger than 1 megabyte. For example, on 5 August 2010, he wrote that "[W]hatever size micropayments you need will eventually be practical. I think in 5 or 10 years, the bandwidth and storage will seem trivial" and "[microtransactions] can become more practical ... if I implement client-only mode and the number of network nodes consolidates into a smaller number of professional server farms" <ref>[https://bitcointalk.org/index.php?topic=532.msg6306#msg6306 the number of network nodes consolidates into a smaller number of professional server farms]</ref>. Satoshi's reasoning was likely based on his belief that SPV would be a primary scaling mechanism. It's since been discovered that SPV security requires strong fraud proofs and the fallback requires ''full node logic.'' <ref>[https://en.bitcoin.it/wiki/User:Gmaxwell/features#Proofs Greg Maxwell's outline of fraud proof logic] Greg Maxwell's wiki page, 22 March, 2013</ref><ref>[https://bitcointalk.org/index.php?topic=96644.msg1064601#msg1064601 Greg Maxwell's early post on fraud proofs] Greg Maxwell on fraud proofs, 30 July, 2012</ref>

In one of Nakamoto's final public messages, he wrote that "Bitcoin users might get increasingly tyrannical about limiting the size of the chain so it's easy for lots of users and small devices."<ref>[https://bitcointalk.org/index.php?topic=1790.msg28917#msg28917 BitDNS and Generalizing Bitcoin], Satoshi Nakamoto, 10 December 2010</ref> This statement suggests that Nakamoto was aware of the value of limiting the block size and that he correctly predicted it was an issue that Bitcoin users would be dealing with in the future---a future Nakamoto may have known would not include him. This was in the context of Satoshi attempting to redirect to a subchain non-Bitcoin uses like DNS data which used direct on-chain block space.

=== What is this Transactions Per Second (TPS) limit? ===

The current block size limit is 1,000,000 bytes (1 megabyte)<ref>[https://github.com/bitcoin/bitcoin/blob/41076aad0cbdfa4c4cf376e345114a5c29086f81/src/consensus/consensus.h#L10 <code>MAX_BLOCK_SIZE</code>], retrieved 2 July 2015</ref>, although a small amount of that space (such as the block header) is not available to store transactions.<ref>[https://bitcoin.org/en/developer-reference#serialized-blocks Block serialization description], Bitcoin.org Developer Reference</ref>

Bitcoin transactions vary in size depending on multiple factors, such as whether they’re spending single-signature inputs or a multiple signature inputs, and how many inputs and outputs they have.

The simple way to calculate the number of Transactions Per Second (TPS) Bitcoin can handle is to divide the block size limit by the expected average size of transactions, divided by the average number of seconds between blocks (600). For example, if you assume average transactions are 250 bytes,

<pre>6.6 TPS = 1,000,000 / 250 / 600</pre>

There seems to be general agreement that Bitcoin in 2015 can handle about 3 TPS with the current average size of transactions.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/007986.html Max TPS based on current average transaction size], Mike Hearn, 8 May 2015</ref><ref name="maxwell_not_proposing">[https://www.reddit.com/r/Bitcoin/comments/39yaod/bitcoinorg_position_on_hard_forks/cs7qz5c "No one proposing 3 TPS forever"], Gregory Maxwell, 15 June 2015</ref>

Both old estimates<ref>[[Scalability]], Bitcoin Wiki, retrieved 7 July
2015</ref> and newer estimates<ref name="garzik_bip" /> placed the pre-segwit
theoretical transaction speed at about 7 TPS.

=== What do devs mean by the scaling expressions O(1), O(n), O(n2), etc…? ===

[https://en.wikipedia.org/wiki/Big_O_notation Big O notation] is a shorthand used by computer scientists to describe how well a system scales. Such descriptions are rough approximations meant to help predict potential problems and evaluate potential solutions; they are not usually expected to fully capture all variables.

* '''O(1)''' means a system has roughly the same properties no matter how big it gets.
* '''O(n)''' means that a system scales linearly: doubling the number of things (users, transactions, etc.) doubles the amount of work.
* '''O(n2)''' means that a system scales quadratically : doubling (2x) the number of things quadruples (4x) the amount of work. Often written O(n^2) is places without convenient superscripts.
* Additional examples may be found in the [https://en.wikipedia.org/wiki/Big_O_notation#Orders_of_common_functions Wikipedia article]

The following subsections show cases where big O notation has been applied to the scaling Bitcoin transaction volume.

==== O(1) block propagation ====

Bitcoin Core relays unconfirmed transactions and then later reconstructs blocks when they are mined while avoiding redundant transaction propagation. The prior transaction double-relay redundancy was eliminated with the invention of a novel block propagation algorithm called Compact Blocks <ref>[https://bitcoincore.org/en/2016/06/07/compact-blocks-faq/ Compact Blocks] Compact Blocks, BIP0152</ref> to allow miners to propagate large blocks very quickly to active network nodes and also significantly reduced miners' need for powerful bandwidth. Miners use a network<ref name="block_relay_net">[http://bitcoinrelaynetwork.org/ Matt Corallo's block relay network]</ref> that is designed for high-bandwidth Wirehair-based<ref>[https://github.com/catid/wirehair Wirehair Github Repository] Wirehair</ref> which is slightly faster still than stock Bitcoin Core.

==== O(n2) network total validation resource requirements with decentralization level held constant ====

[[File:On2_scaling_illustrated.png|thumb|right|visualization of O(n2) scaling]]

While the validation effort required per full node simply grows in O(n), the combined validation effort of all nodes grows by O(n2) '''in the domain of resource consumption'', decentralization being held constant. For a single node, it takes twice as many resources to process the transactions of twice as many users, while for all nodes it takes a combined four times as many CPU resources to process the transactions of twice as many users assuming the number of full nodes increases in proportion to the number of users.

Each on-chain Bitcoin transaction needs to be processed by each full node. If we assume that a certain percentage of users run full nodes (''n'') and that each user creates a certain number of transactions on average (''n'' again), then the network’s total resource requirements are <code>n2 = n * n</code>. In short, this means that the aggregate cost of handling all transactions on-chain quadruples each time the number of users doubles.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009199.html Total system cost], Dr. Adam Back, 28 June 2015</ref> For example,

* Imagine a network starts with 100 users and 2 total nodes (a 2% ratio).

* The network doubles in users to 200. The number of nodes also doubles to 4 (maintaining a 2% ratio of decentralized low-trust security). However, double the number of users means double the number of transactions, and each node needs to process ''every'' transaction---so each node now does double work with its bandwidth and its CPU. With double the number of nodes and double the amount of work per node, total work increases by four times.

* The network doubles again: 400 users, 8 nodes (still 2% of total), and 4 times the original workload per node for a total of 16 times as much aggregate work as the original.

* Another doubling: 800 users, 16 nodes (still 2%), and 8 times the original workload per node for a total of 64 times aggregate work as the original.

* Another doubling: 1,600 users—sixteen times the original---with 32 nodes (still 2%), and 16 times the original workload per node. The aggregate total work done by nodes is 256 times higher than it was originally.

===== Criticisms =====

Emphasis on the total validation resource requirements is suggested by some individuals to be misleading, as they claim it obfuscates the growth of the supporting base of full nodes that the total validation resource effort is split amongst. The validation resource effort made by each individual full node increases at O(n), and critics say this is the only pertinent fact with respect to scaling. Some critics also point out that the O(n2) network total validation resource requirements claim is assuming decentralization must be held constant as the network scales, and that this is not a founding principle of Bitcoin. Of course, as quoted above, Satoshi knew that decentralization would be a critical value of the safety of the system in the first place by demonstrating he could foresee multiple paths for the future of Bitcoin.

=== What’s the difference between on-chain and off-chain transactions? ===

On-chain Bitcoin transactions are those that appear in the Bitcoin block chain. Off-chain transactions are those that transfer ownership of bitcoins without putting a transaction on the block chain.

Common and proposed off-chain transactions include:

* '''Exchange transactions:''' when you buy or sell bitcoins, the exchange tracks ownership in a database without putting data in the block chain. Only when you deposit or withdraw bitcoins does the transaction appear on the block chain.
* '''Web wallet internal payments:''' many web wallets allow users of the service to pay other users of the same service using off-chain payments. For example, when one Coinbase user pays another Coinbase user. '''WARNING: Web wallets are extremely unsafe and many users have had funds stolen from them worth many hundreds of millions of dollars in today's exchange rates.'''
* '''Tipping services:''' most tipping services todayvuse off-chain transactions for everything except deposits and withdrawals from their services.
* '''Payment channels:''' channels are started using one on-chain transaction and ended using a second on-chain transaction.<ref>[https://bitcoin.org/en/developer-guide#micropayment-channel Micropayment channels], Bitcoin.org Developer Guide</ref> In between can be an essentially unlimited number of off-chain transactions as small as a single satoshi (1/100,000,000th of a bitcoin). Payment channels include those that were baked into the protocol at release as well as proposed hub-and-spoke channels and the more advanced [http://lightning.network/ Lightning network].

The vast majority of all bitcoin-denominated payments today are made off-chain.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008844.html Pure off-chain is a weak form of layer 2], Dr. Adam Back, 19 June 2015</ref>

=== What is a fee market? ===

When you create a Bitcoin transaction, you have the option to pay a [[transaction fee]]. If your software is flexible, you can pay anything from zero fees (a free transaction) to 100% of the value of the transaction (spend-to-fees). This fee is comparable to a tip. The higher it is, the bigger the incentive of the miners to incorporate your transaction into the next block.

When miners assemble a block, they are free to include whatever transactions they wish. They usually include as many as possible up to the maximum block size and then prioritize the transactions that pay the most fees per kilobyte of data.<ref name="fee_pri">[https://bitcointalk.org/index.php?topic=95837.0 Fee prioritization patch], Gavin Andresen, 26 July 2012</ref> This usually results in higher-fee transactions confirming before lower-fee transactions. If blocks become full on a regular basis, users who pay a fee that's too small will have to wait a longer and longer time for their transactions to confirm. At this point, a demand-driven fee market will arise where transactions that pay higher fees get confirmed significantly faster than transactions that pay low fees.<ref name="todd_coinwallet">[https://gist.github.com/petertodd/8e87c782bdf342ef18fb Comments on the CoinWallet.eu tx-flood stress-test], Peter Todd, 22 June 2015</ref><ref name="garzik_bip" />

In a competitive market, prices are driven by supply and demand and the emerging equilibrium price asymptotically approaches marginal costs over time. However, the current version of segwit-enabled Bitcoin limits the supply to 4 MW (4 million weight units) per block, allowing only demand to adjust. It turns out that a fee market can stabilize as long as there is a block size limit.<ref>[https://medium.com/@bergealex4/bitcoin-is-unstable-without-the-block-size-size-limit-70db07070a54 Bitcoin is unstable without a block size limit], Alex B., 24 Oct 2016</ref> Simply allowing individual miners to include as many transactions as they want is problematic due to the externalities<ref name="exernality">[https://en.wikipedia.org/wiki/Externality Definition of externality], Wikipedia, 26 January 2016</ref> of including additional blocks and explained further in section [[#Should miners be allowed to decide the block size?|'should miners be allowed to decide the block size?']] .

=== The naive way to scale Bitcoin ===

If Bitcoin decentralization is abandoned, whatever is left could scale limitlessly as a plain database-backed ledger. Mining uses enormous amounts of electricity to provide a secure, verifiable decentralized ledger and full nodes use an enormous amount of bandwidth and CPU time keeping miners honest.

To wit, if users instead decided to hand authority over to someone they trusted, mining and keeping miners honest wouldn’t be necessary. This is how Visa, MasterCard, PayPal, and the rest of the centralized payment systems works—users trust them, and they have no special difficulty scaling to [[scalability|millions of transactions an hour]]. It’s comparatively energy-efficient; it isn’t decentralized, and thus isn't efficient to the ''purpose that Bitcoin was designed to accommodate.''

=== What is a hard fork, and how does it differ from other types of forks? ===

The word fork is badly overloaded in Bitcoin development. The following terms are used, for example:

* '''[[hardfork|Hard fork]]:''' a change to the system which is not backwards compatible. Everyone needs to upgrade or things will go wrong.
* '''[[softfork|Soft fork]]:''' a change to the system which is backwards compatible as long as a majority of miners enforce it. Full nodes that don’t upgrade potentially but not necessarily have reduced security.
* '''Chain fork:''' when there are two are more blocks at the same height on a block chain. This typically happens a few times a week by accident, but it can also indicate more severe problems.
* '''[https://en.wikipedia.org/wiki/Fork_%28software_development%29 Software fork]:''' using the code from an open source project to create a different project.
* '''[https://help.github.com/articles/fork-a-repo/ Git/GitHub fork]:''' a way for developers to write and test new features before contributing them to a project.

(There are other types of software-related forks, but they don’t tend to cause as much confusion.)

=== What are the block size soft limits? ===

Bitcoin Core has historically come pre-configured to limit blocks it mines to certain sizes.<ref name="fee_pri" /> These “limits” aren’t restrictions placed on miners by other miners or nodes, but rather configuration options that help miners produce reasonably-sized blocks.

Miners can change their soft limit size (up to 4 MW) using <code>-blockmaxweight=<size></code>

Default soft limits at various times:

* '''July 2012:''' <code>-blockmaxsize</code> option created and set to default 250 KB soft limit<ref>[https://github.com/bitcoin/bitcoin/commit/c555400ca134991e39d5e3a565fcd2215abe56f6 Bitcoin Core commit c555400], Gavin Andresen, 12 July 2012</ref>
* '''November 2013:''' Raised to 750KB<ref>[https://github.com/bitcoin/bitcoin/commit/ad898b40aaf06c1cc7ac12e953805720fc9217c0 Bitcoin Core commit ad898b40], Gavin Andresen, 27 November 2013</ref>
* '''June 2015:''' Raise to 1 MB suggested<ref>[https://github.com/bitcoin/bitcoin/pull/6231 Bitcoin Core pull #6231], Chris Wheeler, 4 June 2015</ref>
* '''August 2017:''' Segwit activates at block 481824<ref>[https://explorer.blockstream.com/block/0000000000000000001c8018d9cb3b742ef25114f27563e3fc4a1902167f9893 Block 481824] August 23, 2017</ref>

== General Block Size Increase Theory ==

==== Why are some people in favour of keeping the block size conservative forever? ====

It is commonly claimed<ref name="garzik_bip" /><ref>[https://epicenterbitcoin.com/podcast/082/ Epicenter Bitcoin podcast #82], Mike Hearn (interviewed), 8 June 2015</ref> that there are people opposed to ever raising the maximum block size limit, but no Bitcoin developers have suggested a permanent blocksize.<ref name="maxwell_not_proposing" />

All developers support raising the maximum size at some point<ref>[https://www.reddit.com/r/Bitcoin/comments/39kqzs/how_about_a_softfork_optin_blocksize_increase/cs5hj8l Nothing magic about 1MB], Dr. Adam Back, 13 June 2015</ref><ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008328.html Regarding size-independent new block propagation], Pieter Wuille, 28 May 2015</ref>—they just disagree about whether now is the correct time.

==== Should miners be allowed to decide the block size? ====

A block may include as little as a single transaction, so miners can always restrict block size. Letting miners choose the maximum block size is more problematic for several reasons:

# '''Miners profit, others pay the cost:''' bigger blocks earn miners more fees, but technically miners can successfully mine without storing block data almost at all.<ref>[https://github.com/bitcoin/bitcoin/pull/5863 Bitcoin Core pull #5863 adding pruning functionality], Suhas Daftuar et al., 6 March 2015</ref> Some miners will SPV mine optimistically on other miners' blocks without even validating anyting. Other users who want full validation security, or who provide services to lightweight wallets, pay the costs of downloading and storing those larger blocks.
# '''Bigger miners can afford more bandwidth:''' each miner needs to download every transaction that they want to include in blocks,<ref name="maxwell_correcting_assumptions" /> which means that they all need high-speed connections. However, a miner with 8.3% of total hash rate can take that cost out of the about 300 BTC they make a day, while a miner with only 0.7% of total hash rate has to take that cost out of only 25 BTC a day. This means bigger miners may logically choose to make bigger blocks even though it may further centralize mining.
# '''Centralized hardware production:''' only a few companies in the world produce efficient mining equipment, and many of them have historically chosen to stop selling to the public.<ref>[http://blogs.wsj.com/venturecapital/2014/09/05/for-kncminer-time-to-forget-selling-bitcoin-machines-to-at-home-miners/ KnCMiner to stop selling to home miners], Wall Street Journal, Yuliya Chernova, 5 September 2014</ref> This prevents ordinary Bitcoin users from participating in the process even if they were willing to pay for mining equipment.
# '''Voting by hash rate favours larger miners:''' voting based on hash rate allows the current hash rate majority (or super-majority) to enforce conditions on the minority. This is similar to a lobby of large businesses being able to get laws passed that may hurt smaller businesses.<ref>[https://www.reddit.com/r/Bitcoin/comments/39kzyt/draft_bip_100_soft_fork_block_size_increase/cs5gvak Miners choosing the block size limit is ill-advised], Meni Rosenfeld, 13 June 2015</ref> This is less of an issue now that miner-signalled activation has been abandoned.
# '''Miners do not care about users:''' this was demonstrated during the [[July 2015 Forks]] where even after miners lost over $50,000 USD in income from mining invalid chains, and even after they were told that long forks harm users, they continued to mine invalid blocks.<ref>[https://bitcointalk.org/index.php?topic=700411.msg11790734#msg11790734 Intention to continue SPV mining], Wang Chun, 4 July 2015</ref>

However, there are also possible justifications for letting miners choose the block size:

# '''Authenticated participants:''' miners are active participants in Bitcoin, and they can prove it by adding data to the blocks they create.<ref>[https://bitcoin.org/en/developer-reference#term-coinbase-field Coinbase field], Bitcoin.org Developer Reference</ref> It is much harder to prove people on Reddit, BitcoinTalk, and elsewhere are real people with an active stake in Bitcoin.
# '''Bigger blocks may cost smaller miners:''' small miners and poorly-connected miners are at a disadvantage if larger blocks are produced<ref name="wuille_centralization" />, and even large and well-connected miners may find that large blocks reduce their profit percentage if the cost of bandwidth rises too high or their stale rate increases.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008355.html F2Pool block size concerns], Chun Wang, 29 May 2015</ref>

==== How could a block size increase affect user security? ====

Bitcoin’s security is highly dependent on the number of active users who protect their bitcoins with a full node like Bitcoin Core. The more active users of full nodes, the harder it is for miners to trick users into accepting fake bitcoins or other frauds.<ref>[https://medium.com/@lopp/bitcoin-nodes-how-many-is-enough-9b8e8f6fd2cf Bitcoin nodes: how many is enough?], Jameson Lopp, 7 June 2015</ref>

Full nodes need to download and verify every block, and most nodes also store blocks plus relay transactions, blocks, and filtered blocks to other users on the network. The bigger blocks become, the more difficult it becomes to do all this, so it is expected that bigger blocks will both reduce the number of users who currently run full nodes and suppress the number of users who decide to start running a full node later.<ref>[https://www.reddit.com/r/Bitcoin/comments/3bae2d/amir_taaki_on_raising_the_block_size_a_lot_of/cslcgmw Block size increases-only will create problems], Dr. Adam Back, 28 June 2015</ref>

In addition, full blocks may increase mining centralization<ref name="wuille_centralization" /> at a time when mining is already so centralized that it makes it easy to reverse transactions which have been confirmed multiple times.<ref>[http://bitcoin.stackexchange.com/questions/32562/when-to-worry-about-1-confirmation-payments/32564#32564 When to worry about one-confirmation payments], David A. Harding, 17 November 2014</ref>

==== How could larger blocks affect proof-of-work (POW) security? ====

Proof of work security is dependent on how much money miners spend on mining equipment. However, to effectively mine blocks, miners also need to spend money on bandwidth to receive new transactions and blocks created by other miners; CPUs to validate received transactions and blocks; and bandwidth to upload new blocks. These additional costs don’t directly contribute to POW security.<ref name="maxwell_correcting_assumptions">[https://www.reddit.com/r/Bitcoin/comments/39tgno/letting_miners_vote_on_the_maximum_block_size_is/cs6rek5 Correcting wrong assumptions about mining], Gregory Maxwell, 15 June 2015</ref>

As block sizes increase, the amount of bandwidth and CPU required also increases. If block sizes increase faster than the costs of bandwidth and CPU decrease, miners will have less money for POW security relative to the gross income they earn.

In addition, larger blocks have a higher risk of becoming stale (orphaned)<ref name="rusty_dsl" />, which directly correlates to lost POW security. For example, if the network average stale rate is 10%, then 10% of POW performed isn't protecting transactions on the block chain.

=== What happens if blocks aren't big enough to include all pending transactions? ===

This is already often the case, so we know that miners will simply queue transactions. The transactions eligible for block inclusion that pay the highest fee per kiloweight will be confirmed earlier than transactions that pay comparatively lower fees.<ref name="fee_pri" />

What happens from there is debated:

* BitcoinJ lead developer Mike Hearn believed in 2015 there would be “crashing nodes, a swelling transaction backlog, a sudden spike in double spending, [and] skyrocketing fees.”<ref>[https://medium.com/@octskyward/crash-landing-f5cc19908e32 Crash Landing], Mike Hearn, 7 May 2015</ref> Clearly this didn't happen, as of late 2020.
* Bitcoin Foundation chief scientist Gavin Andresen believed in 2015 that the “average transaction fee paid will rise, people or applications unwilling or unable to pay the rising fees will stop submitting transactions, [and] people and businesses will shelve plans to use Bitcoin, stunting growth and adoption.” <ref>[https://github.com/bitcoin/bitcoin/pull/6341 Bitcoin Core pull #6341], Gavin Andresen, 26 June 2015</ref> Clearly, this didn't happen either, as of late 2020.
* Bitcoin Core developer Pieter Wuille replied in 2015 to Andresen’s comment above: “Is it fair to summarize this as ‘Some use cases won’t fit any more, people will decide to no longer use the blockchain for these purposes, and the fees will adapt.’? I think that is already happening […] I don’t think we should be afraid of this change or try to stop it.” <ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009098.html The need for larger blocks], Pieter Wuille, 26 June 2015</ref>

== Segregated Witness ==

Segregated Witness, a block size increase proposal implemented as a soft-fork and which increased the block size to 4 megabytes (actually 4 mega-weight units but strictly-speaking that is contained within 4 megabytes maximum) was adopted as the Bitcoin blocksize increase in August 2017 in block <ref>[https://explorer.blockstream.com/block/0000000000000000001c8018d9cb3b742ef25114f27563e3fc4a1902167f9893 Block 481824] Block 481824</ref> which was most favoured by the user community, in spite of significant political pressure against it by signalling miners and attackers. Segwit was eventually forced into activation by James Hilliard's BIP0091<ref>[https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki BIP 0091], James Hilliard, May 22, 2017.</ref>

== Specific Scaling Proposals (for historical interest) ==

=== Andresen-Hearn Block Size Increase Proposals ===

Questions about the series of related proposals by Gavin Andresen and Mike Hearn to use a hard fork to raise the maximum block size, thereby allowing miners to include more on-chain transactions. As of July 2015, the current focus was [https://github.com/bitcoin/bips/pull/163 BIP101].

==== What was the major advantage of this proposal? ====

''Bitcoin can support many more users.'' Assuming earliest possible adoption, 250 bytes per on-chain transaction, 144 blocks per day, and 2 transaction a day per user, Bitcoin can support about,

* 288,000 users in 2015
* 2,304,000 users in 2016 (800% increase)
* 4,608,000 in 2018 (1,600%)
* 9,216,000 in 2020 (3,200%)
* 18,432,000 in 2022 (6,400%)
* 36,864,000 in 2024 (12,800%)
* 73,728,000 in 2026 (25,600%)
* 147,456,000 in 2028 (51,200%)
* 294,912,000 in 2030 (102,400%)
* 589,824,000 in 2032 (204,800%)
* 1,179,648,000 in 2034 (409,600%
* 2,359,296,000 in 2036 (819,200%)

==== What is the major disadvantage of this proposal? ====

''The total cost of remaining decentralized will be high.'' Assuming earliest possible adoption and that the ratio of total users to full node operators remains the same as today, the total estimated amount of work necessary to maintain the decentralized system under the [[#O.28n2.29_network_total_validation_resource_requirements|O(2) scaling model]] will be,

* 100% of today’s work in 2015
* 6,400% in 2016
* 25,600% in 2018
* 102,400% in 2020
* 409,600% in 2022
* 1,638,400% in 2024
* 6,553,600% in 2026
* 26,214,400% in 2028
* 104,857,600% in 2030
* 419,430,400% in 2032
* 1,677,721,600% in 2034
* 6,710,886,400% in 2036

For example, if the total amount spent on running full nodes today (not counting mining) is $100 thousand per year, the estimated cost for the same level of decentralization in 2036 will be $6.7 trillion per year if validation costs stay the same. (They'll certainly go down, but algorithmic and hardware improvements probably won't eliminate an approximate 6,710,886,400% cost increase.)

==== What are the dangers of the proposed hard fork? ====

Under the then-current current proposal, 75% of miners must indicate that they agree to accept blocks up to 8 MB in size.<ref name="bip101">[https://github.com/bitcoin/bips/pull/163 BIP101], Gavin Andresen, 24 June 2016</ref> After the change goes into effect, if any miner creates a block larger than 1 MB, all nodes which have not upgraded yet will reject the block.<ref>[https://bitcoin.org/en/developer-guide#consensus-rule-changes Consensus rule changes], Bitcoin.org Developer Guide</ref>

If all full nodes have upgraded, or very close to all nodes, there should be no practical effect. If a significant number of full nodes have not upgraded, they will continue using a different block chain than the upgraded users, with the following consequences:

* Bitcoins received from before the fork can be spent twice, once on both sides of the fork. This creates a high double spend risk.
* Bitcoins received after the fork are only guaranteed to be spendable on the side of the fork they were received on. This means some users will have to lose money to restore Bitcoin to a single chain.

Users of hosted wallets (Coinbase, BlockChain.info, etc.) will use whatever block chain their host chooses. Users of lightweight P2P SPV wallets will use the [[Thin Client Security|longest chain they know of]], which may not be the actual longest chain if they only connect to nodes on the shorter chain. Users of non-P2P SPV wallets, like Electrum, will use whatever chain is used by the server they connect to.

If a bad hard fork like this happens, it will likely cause large-scale confusion and make Bitcoin very hard to use until the situation is resolved.

==== What is the deployment schedule for BIP 101? ====

* The patch needs to be accepted into Bitcoin Core, Bitcoin XT, or both.
* If accepted into Bitcoin Core, miners using that software will need to upgrade (this probably requires a new released version of Bitcoin Core). If accepted only into Bitcoin XT, miners will need to switch to using XT.
* After 75% of miners have upgraded, 8MB blocks will become allowed at the the latest of (1) 11 January 2016 or (2) two weeks after the 75% upgrade threshold.<ref name="bip101" />
* After the effective date has passed, any miner may create a block larger than 8MB. When a miner does this, upgraded full nodes will accept that block and non-upgraded full nodes will reject it, forking the network.<ref name="bip101" /> See [[#What_are_the_dangers_of_the_proposed_hard_fork.3F|hard fork dangers]] for what his might mean.

==== Will miners go straight from 1 MB blocks to 8 MB blocks? ====

That would be highly unlikely. Uploading an 8 MB block currently takes significantly more time than uploading a 1 MB block<ref name="rusty_dsl">[http://rusty.ozlabs.org/?p=509 Mining on a home DSL connection test results], Rusty Russell, 19 June 2015</ref>, even with the roughly 25x reduction in size available from use of Matt Corallo’s block relay network.<ref name="block_relay_net" />

The longer it takes to upload a block, the higher the risk it will become a stale block—meaning the miner who created it will not receive the block subsidy or transaction fees (currently about 25 BTC per block).

However, if technology like Invertible Bloom Lookup Tables (IBLTs) is deployed and found to work as expected<ref name="iblt">[https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2 O(1) block propagation], Gavin Andresen, 8 August 2014</ref>, or if mining [[#What_is_the_most_efficient_way_to_scale_Bitcoin.3F|centralizes further]], adding additional transactions may not have a significant enough cost to discourage miners from creating full blocks. In that case, blocks will be filled as soon as there are enough people wanting to make transactions paying the default relay fee<ref>[https://github.com/bitcoin/bitcoin/pull/3305 Bitcoin Core pull #3305 dropping default fees], Mike Hearn, 22 November 2013</ref> of 0.00001000 BTC/kilobyte.

==== What tests have been performed related to this proposal? ====

* '''20MB block processing''' (Gavin Andresen) “if we increased the maximum block size to 20 megabytes tomorrow, and every single miner decided to start creating 20MB blocks and there was a sudden increase in the number of transactions on the network to fill up those blocks… the 0.10.0 version of [Bitcoin Core] would run just fine.”<ref>[http://gavintech.blogspot.com/2015/01/twenty-megabytes-testing-results.html Twenty megabyte block testing], Gavin Andresen, 20 January 2015</ref> (ellipses in original)
* '''Mining & relay simulation''' (Gavin Andresen) “if blocks take 20 seconds to propagate, a network with a miner that has 30% of the hashing power will get 30.3% of the blocks.”<ref>[http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners Are bigger blocks better for bigger miners?], Gavin Andresen, 22 May 2015</ref>
* '''Mining on a home DSL connection''' (Rusty Russell) “Using the rough formula of 1-exp(-t/600), I would expect orphan rates of 10.5% generating 1MB blocks, and 56.6% with 8MB blocks; that’s a huge cut in expected profits.”<ref name="rusty_dsl" />
* '''Mining centralization pressure''' (Pieter Wuille) “[This] does very clearly show the effects of larger blocks on centralization pressure of the system.”<ref name="wuille_centralization">[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008581.html Mining centralization pressure from non-uniform propagation speed], Pieter Wuille, 12 June 2015</ref>

=== Garzik Miner Block Size Voting Proposal (AKA BIP100) ===

''Note, BIP 100 is the marketing name for this proposal. No BIP number
has yet been publicly requested, and the number assigned is unlikely to
be 100.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-May/005756.html
Prenumbered BIP naming], Gregory Maxwell, 12 May 2014</ref>''

Questions related to Jeff Garzik's proposal<ref name="garzik_bip">[http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf Draft BIP: decentralized economic policy], Jeff Garzik, 12 June 2015 (revised 15 June 2015)</ref> to allow miners to vote on raising and lowering the maximum block size.

==== What does this proposal do? ====

# It creates a one-time hard fork that does not automatically change the maximum block size.

# It allows miners to vote to increase or decrease the maximum block size within the range of 1MB to 32MB. These changes are neither hard forks nor soft forks, but simply rules that all nodes should know about after the initial hard fork.

==== Does it reduce the risk of a hard fork? ====

Hard forks are most dangerous when they're done without strong
consensus.<ref name="garzik_bip" /><ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008779.html Consensus changes are not about making a change to the software],
Pieter Wuille, 18 June 2015</ref>

If Garzik's proposal gains strong consensus, it will be as safe as possible
for a hard fork and it will allow increasing the block size up to 32 MB
without any additional risk of a fork.

==== Why is it limited to 32 megabytes? ====

According to the draft BIP, "the 32 MB hard fork is largely coincidental -- a whole network upgrade at 32 MB was likely needed anyway."

=== Lightning Network ===

Questions related to using the proposed [http://lightning.network/ Lightning network] as a way to scale the number of users Bitcoin can support.

==== How does transaction security differ from that of Bitcoin? ====

Transactions on the proposed Lightning network use Bitcoin transactions exclusively to transfer bitcoins<ref name="russell_lightning1">[http://rusty.ozlabs.org/?p=450 Lightning Networks: Part I], Rusty Russell, 30 March 2015</ref>, and so the same security as regular Bitcoin transactions is provided when both a Lightning hub and client are cooperating.

When a Lightning hub or client refuses to cooperate with the other (maybe because they accidentally went offline), the other party can still receive their full 100% bitcoin balance by closing the payment channel—but they must first wait for a defined amount of time mutually chosen by both the hub and client.<ref>[http://rusty.ozlabs.org/?p=462 Lightning Networks: Part II], Rusty Russell, 1 April 2015</ref>

If one party waits too long to close the payment channel, the other party may be able to steal bitcoins. However, it is possible to delegate the task of closing the channel in an emergency to an unlimited number of hubs around the Internet, so closing the channel on time should be easy.<ref name="russell_lightning4">[http://rusty.ozlabs.org/?p=477 Lightning Networks: Part IV], Rusty Russell, 8 April 2015</ref>

In summary, provided that payment channels are closed on time, the worst that can happen to users is that they may have to wait a few weeks for a channel to fully close before spending the bitcoins they received from it. Their security is otherwise the same as with regular Bitcoin.

For Lightning hubs, security is slightly worse in the sense that they need to keep a potentially-large amount of funds in a hot wallet<ref name="lightning_paper">[http://lightning.network/lightning-network-paper-DRAFT-0.5.pdf Lightning Network (Draft 0.5)], Section 6.3: Coin Theft via Hacking, Joseph Poon and Thaddeus Dryja</ref>, so they can’t take advantage of the anti-hacking protection offered by cold wallets. Otherwise, Lightning hubs have the same security as clients.

==== When will Lightning be ready for use? ====

Lightning requires a basic test implementation (work underway<ref>[https://lists.blockstream.com/pipermail/lightning-dev/2015-June/000018.html Lightning first steps], Rusty Russell, 13 June 2015</ref>), several soft-fork changes to the Bitcoin protocol (work underway<ref>[https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65: CheckLockTimeVerify], Peter Todd, 1 October 2014</ref><ref>[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68: Consensus-enforced transaction replacement], Mark Friedenbach, 28 May 2015</ref>, and wallets need to be updated to support the Lightning network protocol.<ref name="russell_lightning4" />

Dr. Adam Back has said, "I expect we can get something running inside a year."<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009242.html Reply to Andresen regarding Lightning], Dr. Adam Back, 28 June 2015</ref>

==== Doesn’t Lightning require bigger blocks anyway? ====

Lightning is block-size neutral. It requires one on-chain transaction to open a channel between a hub and a client, and one on-chain transaction to close a channel.<ref name="russell_lightning1" /> In between it can support an unlimited number of transactions between anyone on the Lightning network.<ref name="lightning_paper" />

Using the numbers from the Lightning presentation<ref name="lightning_slides">[http://lightning.network/lightning-network.pdf Lightning presentation], Joseph Poon, 23 February 2015</ref>, if people open and close a plausible two channels a year, Lightning can support about 52 million users with the current one-megabyte limit—and each user can make an unlimited number of transactions. Currently, assuming people make an average of only two Bitcoin transactions a day, basic Bitcoin can support only 288,000 users.

Under these assumptions, Lightning is 180 times (17,900%) more efficient than basic Bitcoin.

Presumably, if around 30 million people are using Bitcoin via Lightning so that capacity is called into question, it will not be difficult to find consensus to double the block size to two megabytes and bring user capacity up to 105 million. The same goes for later increases to 200 million (4MB), 400 million (8MB), 800 million (16MB), 1.6 billion (32 MB), 3.2 billion (64MB), and all 7 billion living humans (133MB). In each case, all Lightning network participants get unlimited transactions to the other participants.

For basic Bitcoin to scale to just 2 transactions a day for 7 billion people would require 24-gigabyte blocks.<ref name="lightning_slides" />

=== Sidechains ===

==== Real quick, what are sidechains? ====

Block chains that are separate from Bitcoin’s block chain, but which allow you to receive and spend bitcoins using a two-way peg (2WP).<ref name="sidechains_paper">[https://www.blockstream.com/sidechains.pdf Sidechains paper], Adam Back et al., 22 October 2014</ref> (Although a sidechain can never be more secure than the Bitcoin block chain.<ref>[https://www.reddit.com/r/Bitcoin/comments/39r85g/sidechain_hate/cs5spbg Security limitations of pegged chains], Gregory Maxwell, 14 June 2015</ref>)

==== Are sidechains a scaling option? ====

No. Sidechains have the same fundamental scaling problems as Bitcoin does. Moving some transactions to sidechains simply moves some problems elsewhere on the network—the total difficulty of the problem remains the same.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008617.html Sidechains not a direct means for solving any of the scaling problems Bitcoin has], Pieter Wuille, 13 June 2015</ref>

==== But couldn’t I create a sidechain that had 100 GB blocks? ====

Certainly, sidechain code is open source<ref>[https://github.com/ElementsProject/elements Elements Project]</ref>—so you can create your own sidechain. But you’d still have the difficulty of finding people who are willing to validate 100 GB blocks with their own full nodes.

==== Do sidechains require a hard fork? ====

No. Federated sidechains, such as have already been implemented<ref>[https://github.com/ElementsProject/elements/tree/alpha Elements Alpha]</ref>, don’t require any changes to the Bitcoin consensus rules. Merged-mined sidechains, which have not been implemented yet, do require a backwards-compatible soft fork in order to transfer funds between Bitcoin and the sidechain.<ref name="sidechains_paper" />

== References ==
<references />

Scalability FAQ

2020-10-14T20:14:07Z

Midnightmagic: holy crap, dunno where this came from but huge chunks of it have been wrong since they were written, and now jerks in rbtc are referencing it, so.. fixing it.

Answers to commonly-asked questions and concerns about scaling Bitcoin, including “level 1” solutions such as increasing the block size and “level 2” solutions such as the proposed Lightning network.

== Background ==

Questions about how Bitcoin currently works (related to scaling) as well as questions about the technical terminology related to the scaling discussion.

=== What is the short history of the block size limit? ===

''Note: the software now called Bitcoin Core was previously simply called “Bitcoin”.<ref>[https://bitcoin.org/en/release/v0.9.0#rebranding-to-bitcoin-core Bitcoin Core 0.9.0 release notes], Bitcoin.org, 19 March 2014</ref>''

Bitcoin Core was initially released with a 32 MiB block size limit.<ref>[https://bitcointalk.org/index.php?topic=68121 Earliest known Bitcoin code], [https://github.com/trottier/original-bitcoin/blob/92ee8d9a994391d148733da77e2bbc2f4acc43cd/src/main.h#L17 src/main.h:17] and [https://github.com/trottier/original-bitcoin/blob/92ee8d9a994391d148733da77e2bbc2f4acc43cd/src/main.cpp#L1160 src/main.cpp:1160]</ref>

Around 15 July 2010, Satoshi Nakamoto changed Bitcoin Core’s mining code so that it wouldn’t create any blocks larger than 990,000 bytes.<ref>[https://github.com/bitcoin/bitcoin/commit/a30b56ebe76ffff9f9cc8a6667186179413c6349 Bitcoin Core commit a30b56e], Satoshi Nakamoto, 15 July 2010</ref>

Two months later on 7 September 2010, Nakamoto changed Bitcoin Core’s consensus rules to reject blocks larger than 1,000,000 bytes (1 megabyte) if their block height was higher than 79,400.<ref>[https://github.com/bitcoin/bitcoin/commit/8c9479c6bbbc38b897dc97de9d04e4d5a5a36730 Bitcoin Core commit 8c9479c], Satoshi Nakamoto, 7 September 2010</ref> (Block 79,400 was later produced on 12 September 2010.<ref>[https://explorer.blockstream.com/block/000000000021d821ec06be7173f413690bc5c4bc648dfa70b3b6763236f055b7 Block height 79400], dated 12 September 2010</ref>)

Neither the July nor the September commit message explains the reason for the limit, although the careful attempt to prevent a fork may indicate Nakamoto didn’t consider it an emergency.

Nakamoto’s subsequent warning not to run a blocksize increase patch which would have destructively forked the network said that '''if''' users needed to increase the blocksize, it '''could''' be accomplished with a planned hardfork at a future time<ref>[https://bitcointalk.org/index.php?topic=1347.msg15139#msg15139 Increasing the block size if needed], Satoshi Nakamoto, 3 October 2010</ref>, but he never specified which conditions might require one.

Statements by Nakamoto in the summer of 2010 indicate he believed Bitcoin could scale to block sizes far larger than 1 megabyte. For example, on 5 August 2010, he wrote that "[W]hatever size micropayments you need will eventually be practical. I think in 5 or 10 years, the bandwidth and storage will seem trivial" and "[microtransactions] can become more practical ... if I implement client-only mode and the number of network nodes consolidates into a smaller number of professional server farms" <ref>[https://bitcointalk.org/index.php?topic=532.msg6306#msg6306 the number of network nodes consolidates into a smaller number of professional server farms]</ref>. Satoshi's reasoning was likely based on his belief that SPV would be a primary scaling mechanism. It's since been discovered that SPV security requires strong fraud proofs and the fallback requires ''full node logic.'' <ref>[https://en.bitcoin.it/wiki/User:Gmaxwell/features#Proofs Greg Maxwell's outline of fraud proof logic] Greg Maxwell's wiki page, 22 March, 2013</ref><ref>[https://bitcointalk.org/index.php?topic=96644.msg1064601#msg1064601 Greg Maxwell's early post on fraud proofs] Greg Maxwell on fraud proofs, 30 July, 2012</ref>

In one of Nakamoto's final public messages, he wrote that "Bitcoin users might get increasingly tyrannical about limiting the size of the chain so it's easy for lots of users and small devices."<ref>[https://bitcointalk.org/index.php?topic=1790.msg28917#msg28917 BitDNS and Generalizing Bitcoin], Satoshi Nakamoto, 10 December 2010</ref> This statement suggests that Nakamoto was aware of the value of limiting the block size and that he correctly predicted it was an issue that Bitcoin users would be dealing with in the future---a future Nakamoto may have known would not include him. This was in the context of Satoshi attempting to redirect to a subchain non-Bitcoin uses like DNS data which used direct on-chain block space.

=== What is this Transactions Per Second (TPS) limit? ===

The current block size limit is 1,000,000 bytes (1 megabyte)<ref>[https://github.com/bitcoin/bitcoin/blob/41076aad0cbdfa4c4cf376e345114a5c29086f81/src/consensus/consensus.h#L10 <code>MAX_BLOCK_SIZE</code>], retrieved 2 July 2015</ref>, although a small amount of that space (such as the block header) is not available to store transactions.<ref>[https://bitcoin.org/en/developer-reference#serialized-blocks Block serialization description], Bitcoin.org Developer Reference</ref>

Bitcoin transactions vary in size depending on multiple factors, such as whether they’re spending single-signature inputs or a multiple signature inputs, and how many inputs and outputs they have.

The simple way to calculate the number of Transactions Per Second (TPS) Bitcoin can handle is to divide the block size limit by the expected average size of transactions, divided by the average number of seconds between blocks (600). For example, if you assume average transactions are 250 bytes,

<pre>6.6 TPS = 1,000,000 / 250 / 600</pre>

There seems to be general agreement that Bitcoin in 2015 can handle about 3 TPS with the current average size of transactions.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/007986.html Max TPS based on current average transaction size], Mike Hearn, 8 May 2015</ref><ref name="maxwell_not_proposing">[https://www.reddit.com/r/Bitcoin/comments/39yaod/bitcoinorg_position_on_hard_forks/cs7qz5c "No one proposing 3 TPS forever"], Gregory Maxwell, 15 June 2015</ref>

Both old estimates<ref>[[Scalability]], Bitcoin Wiki, retrieved 7 July
2015</ref> and newer estimates<ref name="garzik_bip" /> placed the pre-segwit
theoretical transaction speed at about 7 TPS.

=== What do devs mean by the scaling expressions O(1), O(n), O(n2), etc…? ===

[https://en.wikipedia.org/wiki/Big_O_notation Big O notation] is a shorthand used by computer scientists to describe how well a system scales. Such descriptions are rough approximations meant to help predict potential problems and evaluate potential solutions; they are not usually expected to fully capture all variables.

* '''O(1)''' means a system has roughly the same properties no matter how big it gets.
* '''O(n)''' means that a system scales linearly: doubling the number of things (users, transactions, etc.) doubles the amount of work.
* '''O(n2)''' means that a system scales quadratically : doubling (2x) the number of things quadruples (4x) the amount of work. Often written O(n^2) is places without convenient superscripts.
* Additional examples may be found in the [https://en.wikipedia.org/wiki/Big_O_notation#Orders_of_common_functions Wikipedia article]

The following subsections show cases where big O notation has been applied to the scaling Bitcoin transaction volume.

==== O(1) block propagation ====

Bitcoin Core relays unconfirmed transactions and then later reconstructs blocks when they are mined while avoiding redundant transaction propagation. The prior transaction double-relay redundancy was eliminated with the invention of a novel block propagation algorithm called Compact Blocks <ref>[https://bitcoincore.org/en/2016/06/07/compact-blocks-faq/ Compact Blocks] Compact Blocks, BIP0152</ref> to allow miners to propagate large blocks very quickly to active network nodes and also significantly reduced miners' need for powerful bandwidth. Miners use a network<ref name="block_relay_net">[http://bitcoinrelaynetwork.org/ Matt Corallo's block relay network]</ref> that is designed for high-bandwidth Wirehair-based<ref>[https://github.com/catid/wirehair Wirehair Github Repository] Wirehair</ref> which is slightly faster still than stock Bitcoin Core.

==== O(n2) network total validation resource requirements with decentralization level held constant ====

[[File:On2_scaling_illustrated.png|thumb|right|visualization of O(n2) scaling]]

While the validation effort required per full node simply grows in O(n), the combined validation effort of all nodes grows by O(n2) '''in the domain of resource consumption'', decentralization being held constant. For a single node, it takes twice as many resources to process the transactions of twice as many users, while for all nodes it takes a combined four times as many CPU resources to process the transactions of twice as many users assuming the number of full nodes increases in proportion to the number of users.

Each on-chain Bitcoin transaction needs to be processed by each full node. If we assume that a certain percentage of users run full nodes (''n'') and that each user creates a certain number of transactions on average (''n'' again), then the network’s total resource requirements are <code>n2 = n * n</code>. In short, this means that the aggregate cost of handling all transactions on-chain quadruples each time the number of users doubles.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009199.html Total system cost], Dr. Adam Back, 28 June 2015</ref> For example,

* Imagine a network starts with 100 users and 2 total nodes (a 2% ratio).

* The network doubles in users to 200. The number of nodes also doubles to 4 (maintaining a 2% ratio of decentralized low-trust security). However, double the number of users means double the number of transactions, and each node needs to process ''every'' transaction---so each node now does double work with its bandwidth and its CPU. With double the number of nodes and double the amount of work per node, total work increases by four times.

* The network doubles again: 400 users, 8 nodes (still 2% of total), and 4 times the original workload per node for a total of 16 times as much aggregate work as the original.

* Another doubling: 800 users, 16 nodes (still 2%), and 8 times the original workload per node for a total of 64 times aggregate work as the original.

* Another doubling: 1,600 users—sixteen times the original---with 32 nodes (still 2%), and 16 times the original workload per node. The aggregate total work done by nodes is 256 times higher than it was originally.

===== Criticisms =====

Emphasis on the total validation resource requirements is suggested by some individuals to be misleading, as they claim it obfuscates the growth of the supporting base of full nodes that the total validation resource effort is split amongst. The validation resource effort made by each individual full node increases at O(n), and critics say this is the only pertinent fact with respect to scaling. Some critics also point out that the O(n2) network total validation resource requirements claim is assuming decentralization must be held constant as the network scales, and that this is not a founding principle of Bitcoin. Of course, as quoted above, Satoshi knew that decentralization would be a critical value of the safety of the system in the first place by demonstrating he could foresee multiple paths for the future of Bitcoin.

=== What’s the difference between on-chain and off-chain transactions? ===

On-chain Bitcoin transactions are those that appear in the Bitcoin block chain. Off-chain transactions are those that transfer ownership of bitcoins without putting a transaction on the block chain.

Common and proposed off-chain transactions include:

* '''Exchange transactions:''' when you buy or sell bitcoins, the exchange tracks ownership in a database without putting data in the block chain. Only when you deposit or withdraw bitcoins does the transaction appear on the block chain.
* '''Web wallet internal payments:''' many web wallets allow users of the service to pay other users of the same service using off-chain payments. For example, when one Coinbase user pays another Coinbase user. '''WARNING: Web wallets are extremely unsafe and many users have had funds stolen from them worth many hundreds of millions of dollars in today's exchange rates.'''
* '''Tipping services:''' most tipping services todayvuse off-chain transactions for everything except deposits and withdrawals from their services.
* '''Payment channels:''' channels are started using one on-chain transaction and ended using a second on-chain transaction.<ref>[https://bitcoin.org/en/developer-guide#micropayment-channel Micropayment channels], Bitcoin.org Developer Guide</ref> In between can be an essentially unlimited number of off-chain transactions as small as a single satoshi (1/100,000,000th of a bitcoin). Payment channels include those that were baked into the protocol at release as well as proposed hub-and-spoke channels and the more advanced [http://lightning.network/ Lightning network].

The vast majority of all bitcoin-denominated payments today are made off-chain.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008844.html Pure off-chain is a weak form of layer 2], Dr. Adam Back, 19 June 2015</ref>

=== What is a fee market? ===

When you create a Bitcoin transaction, you have the option to pay a [[transaction fee]]. If your software is flexible, you can pay anything from zero fees (a free transaction) to 100% of the value of the transaction (spend-to-fees). This fee is comparable to a tip. The higher it is, the bigger the incentive of the miners to incorporate your transaction into the next block.

When miners assemble a block, they are free to include whatever transactions they wish. They usually include as many as possible up to the maximum block size and then prioritize the transactions that pay the most fees per kilobyte of data.<ref name="fee_pri">[https://bitcointalk.org/index.php?topic=95837.0 Fee prioritization patch], Gavin Andresen, 26 July 2012</ref> This usually results in higher-fee transactions confirming before lower-fee transactions. If blocks become full on a regular basis, users who pay a fee that's too small will have to wait a longer and longer time for their transactions to confirm. At this point, a demand-driven fee market will arise where transactions that pay higher fees get confirmed significantly faster than transactions that pay low fees.<ref name="todd_coinwallet">[https://gist.github.com/petertodd/8e87c782bdf342ef18fb Comments on the CoinWallet.eu tx-flood stress-test], Peter Todd, 22 June 2015</ref><ref name="garzik_bip" />

In a competitive market, prices are driven by supply and demand and the emerging equilibrium price asymptotically approaches marginal costs over time. However, the current version of segwit-enabled Bitcoin limits the supply to 4 MW (4 million weight units) per block, allowing only demand to adjust. It turns out that a fee market can stabilize as long as there is a block size limit.<ref>[https://medium.com/@bergealex4/bitcoin-is-unstable-without-the-block-size-size-limit-70db07070a54 Bitcoin is unstable without a block size limit], Alex B., 24 Oct 2016</ref> Simply allowing individual miners to include as many transactions as they want is problematic due to the externalities<ref name="exernality">[https://en.wikipedia.org/wiki/Externality Definition of externality], Wikipedia, 26 January 2016</ref> of including additional blocks and explained further in section [[#Should miners be allowed to decide the block size?|'should miners be allowed to decide the block size?']] .

=== The naive way to scale Bitcoin ===

If Bitcoin decentralization is abandoned, whatever is left could scale limitlessly as a plain database-backed ledger. Mining uses enormous amounts of electricity to provide a secure, verifiable decentralized ledger and full nodes use an enormous amount of bandwidth and CPU time keeping miners honest.

To wit, if users instead decided to hand authority over to someone they trusted, mining and keeping miners honest wouldn’t be necessary. This is how Visa, MasterCard, PayPal, and the rest of the centralized payment systems works—users trust them, and they have no special difficulty scaling to [[scalability|millions of transactions an hour]]. It’s comparatively energy-efficient; it isn’t decentralized, and thus isn't efficient to the ''purpose that Bitcoin was designed to accommodate.''

=== What is a hard fork, and how does it differ from other types of forks? ===

The word fork is badly overloaded in Bitcoin development. The following terms are used, for example:

* '''[[hardfork|Hard fork]]:''' a change to the system which is not backwards compatible. Everyone needs to upgrade or things will go wrong.
* '''[[softfork|Soft fork]]:''' a change to the system which is backwards compatible as long as a majority of miners enforce it. Full nodes that don’t upgrade potentially but not necessarily have reduced security.
* '''Chain fork:''' when there are two are more blocks at the same height on a block chain. This typically happens a few times a week by accident, but it can also indicate more severe problems.
* '''[https://en.wikipedia.org/wiki/Fork_%28software_development%29 Software fork]:''' using the code from an open source project to create a different project.
* '''[https://help.github.com/articles/fork-a-repo/ Git/GitHub fork]:''' a way for developers to write and test new features before contributing them to a project.

(There are other types of software-related forks, but they don’t tend to cause as much confusion.)

=== What are the block size soft limits? ===

Bitcoin Core has historically come pre-configured to limit blocks it mines to certain sizes.<ref name="fee_pri" /> These “limits” aren’t restrictions placed on miners by other miners or nodes, but rather configuration options that help miners produce reasonably-sized blocks.

Miners can change their soft limit size (up to 4 MW) using <code>-blockmaxweight=<size></code>

Default soft limits at various times:

* '''July 2012:''' <code>-blockmaxsize</code> option created and set to default 250 KB soft limit<ref>[https://github.com/bitcoin/bitcoin/commit/c555400ca134991e39d5e3a565fcd2215abe56f6 Bitcoin Core commit c555400], Gavin Andresen, 12 July 2012</ref>
* '''November 2013:''' Raised to 750KB<ref>[https://github.com/bitcoin/bitcoin/commit/ad898b40aaf06c1cc7ac12e953805720fc9217c0 Bitcoin Core commit ad898b40], Gavin Andresen, 27 November 2013</ref>
* '''June 2015:''' Raise to 1 MB suggested<ref>[https://github.com/bitcoin/bitcoin/pull/6231 Bitcoin Core pull #6231], Chris Wheeler, 4 June 2015</ref>
* '''August 2017:''' Segwit activates at block 481824<ref>[https://explorer.blockstream.com/block/0000000000000000001c8018d9cb3b742ef25114f27563e3fc4a1902167f9893 Block 481824] August 23, 2017</ref>

== General Block Size Increase Theory ==

==== Why are some people in favour of keeping the block size conservative forever? ====

It is commonly claimed<ref name="garzik_bip" /><ref>[https://epicenterbitcoin.com/podcast/082/ Epicenter Bitcoin podcast #82], Mike Hearn (interviewed), 8 June 2015</ref> that there are people opposed to ever raising the maximum block size limit, but no Bitcoin developers have suggested a permanent blocksize.<ref name="maxwell_not_proposing" />

All developers support raising the maximum size at some point<ref>[https://www.reddit.com/r/Bitcoin/comments/39kqzs/how_about_a_softfork_optin_blocksize_increase/cs5hj8l Nothing magic about 1MB], Dr. Adam Back, 13 June 2015</ref><ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008328.html Regarding size-independent new block propagation], Pieter Wuille, 28 May 2015</ref>—they just disagree about whether now is the correct time.

==== Should miners be allowed to decide the block size? ====

A block may include as little as a single transaction, so miners can always restrict block size. Letting miners choose the maximum block size is more problematic for several reasons:

# '''Miners profit, others pay the cost:''' bigger blocks earn miners more fees, but technically miners can successfully mine without storing block data almost at all.<ref>[https://github.com/bitcoin/bitcoin/pull/5863 Bitcoin Core pull #5863 adding pruning functionality], Suhas Daftuar et al., 6 March 2015</ref> Some miners will SPV mine optimistically on other miners' blocks without even validating anyting. Other users who want full validation security, or who provide services to lightweight wallets, pay the costs of downloading and storing those larger blocks.
# '''Bigger miners can afford more bandwidth:''' each miner needs to download every transaction that they want to include in blocks,<ref name="maxwell_correcting_assumptions" /> which means that they all need high-speed connections. However, a miner with 8.3% of total hash rate can take that cost out of the about 300 BTC they make a day, while a miner with only 0.7% of total hash rate has to take that cost out of only 25 BTC a day. This means bigger miners may logically choose to make bigger blocks even though it may further centralize mining.
# '''Centralized hardware production:''' only a few companies in the world produce efficient mining equipment, and many of them have historically chosen to stop selling to the public.<ref>[http://blogs.wsj.com/venturecapital/2014/09/05/for-kncminer-time-to-forget-selling-bitcoin-machines-to-at-home-miners/ KnCMiner to stop selling to home miners], Wall Street Journal, Yuliya Chernova, 5 September 2014</ref> This prevents ordinary Bitcoin users from participating in the process even if they were willing to pay for mining equipment.
# '''Voting by hash rate favours larger miners:''' voting based on hash rate allows the current hash rate majority (or super-majority) to enforce conditions on the minority. This is similar to a lobby of large businesses being able to get laws passed that may hurt smaller businesses.<ref>[https://www.reddit.com/r/Bitcoin/comments/39kzyt/draft_bip_100_soft_fork_block_size_increase/cs5gvak Miners choosing the block size limit is ill-advised], Meni Rosenfeld, 13 June 2015</ref> This is less of an issue now that miner-signalled activation has been abandoned.
# '''Miners do not care about users:''' this was demonstrated during the [[July 2015 Forks]] where even after miners lost over $50,000 USD in income from mining invalid chains, and even after they were told that long forks harm users, they continued to mine invalid blocks.<ref>[https://bitcointalk.org/index.php?topic=700411.msg11790734#msg11790734 Intention to continue SPV mining], Wang Chun, 4 July 2015</ref>

However, there are also possible justifications for letting miners choose the block size:

# '''Authenticated participants:''' miners are active participants in Bitcoin, and they can prove it by adding data to the blocks they create.<ref>[https://bitcoin.org/en/developer-reference#term-coinbase-field Coinbase field], Bitcoin.org Developer Reference</ref> It is much harder to prove people on Reddit, BitcoinTalk, and elsewhere are real people with an active stake in Bitcoin.
# '''Bigger blocks may cost smaller miners:''' small miners and poorly-connected miners are at a disadvantage if larger blocks are produced<ref name="wuille_centralization" />, and even large and well-connected miners may find that large blocks reduce their profit percentage if the cost of bandwidth rises too high or their stale rate increases.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008355.html F2Pool block size concerns], Chun Wang, 29 May 2015</ref>

==== How could a block size increase affect user security? ====

Bitcoin’s security is highly dependent on the number of active users who protect their bitcoins with a full node like Bitcoin Core. The more active users of full nodes, the harder it is for miners to trick users into accepting fake bitcoins or other frauds.<ref>[https://medium.com/@lopp/bitcoin-nodes-how-many-is-enough-9b8e8f6fd2cf Bitcoin nodes: how many is enough?], Jameson Lopp, 7 June 2015</ref>

Full nodes need to download and verify every block, and most nodes also store blocks plus relay transactions, blocks, and filtered blocks to other users on the network. The bigger blocks become, the more difficult it becomes to do all this, so it is expected that bigger blocks will both reduce the number of users who currently run full nodes and suppress the number of users who decide to start running a full node later.<ref>[https://www.reddit.com/r/Bitcoin/comments/3bae2d/amir_taaki_on_raising_the_block_size_a_lot_of/cslcgmw Block size increases-only will create problems], Dr. Adam Back, 28 June 2015</ref>

In addition, full blocks may increase mining centralization<ref name="wuille_centralization" /> at a time when mining is already so centralized that it makes it easy to reverse transactions which have been confirmed multiple times.<ref>[http://bitcoin.stackexchange.com/questions/32562/when-to-worry-about-1-confirmation-payments/32564#32564 When to worry about one-confirmation payments], David A. Harding, 17 November 2014</ref>

==== How could larger blocks affect proof-of-work (POW) security? ====

Proof of work security is dependent on how much money miners spend on mining equipment. However, to effectively mine blocks, miners also need to spend money on bandwidth to receive new transactions and blocks created by other miners; CPUs to validate received transactions and blocks; and bandwidth to upload new blocks. These additional costs don’t directly contribute to POW security.<ref name="maxwell_correcting_assumptions">[https://www.reddit.com/r/Bitcoin/comments/39tgno/letting_miners_vote_on_the_maximum_block_size_is/cs6rek5 Correcting wrong assumptions about mining], Gregory Maxwell, 15 June 2015</ref>

As block sizes increase, the amount of bandwidth and CPU required also increases. If block sizes increase faster than the costs of bandwidth and CPU decrease, miners will have less money for POW security relative to the gross income they earn.

In addition, larger blocks have a higher risk of becoming stale (orphaned)<ref name="rusty_dsl" />, which directly correlates to lost POW security. For example, if the network average stale rate is 10%, then 10% of POW performed isn't protecting transactions on the block chain.

=== What happens if blocks aren't big enough to include all pending transactions? ===

This is already often the case, so we know that miners will simply queue transactions. The transactions eligible for block inclusion that pay the highest fee per kiloweight will be confirmed earlier than transactions that pay comparatively lower fees.<ref name="fee_pri" />

What happens from there is debated:

* BitcoinJ lead developer Mike Hearn believed in 2015 there would be “crashing nodes, a swelling transaction backlog, a sudden spike in double spending, [and] skyrocketing fees.”<ref>[https://medium.com/@octskyward/crash-landing-f5cc19908e32 Crash Landing], Mike Hearn, 7 May 2015</ref> Clearly this didn't happen, as of late 2020.
* Bitcoin Foundation chief scientist Gavin Andresen believed in 2015 that the “average transaction fee paid will rise, people or applications unwilling or unable to pay the rising fees will stop submitting transactions, [and] people and businesses will shelve plans to use Bitcoin, stunting growth and adoption.” <ref>[https://github.com/bitcoin/bitcoin/pull/6341 Bitcoin Core pull #6341], Gavin Andresen, 26 June 2015</ref> Clearly, this didn't happen either, as of late 2020.
* Bitcoin Core developer Pieter Wuille replied in 2015 to Andresen’s comment above: “Is it fair to summarize this as ‘Some use cases won’t fit any more, people will decide to no longer use the blockchain for these purposes, and the fees will adapt.’? I think that is already happening […] I don’t think we should be afraid of this change or try to stop it.” <ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009098.html The need for larger blocks], Pieter Wuille, 26 June 2015</ref>

== Specific Scaling Proposals (for historical interest) ==

=== Andresen-Hearn Block Size Increase Proposals ===

Questions about the series of related proposals by Gavin Andresen and Mike Hearn to use a hard fork to raise the maximum block size, thereby allowing miners to include more on-chain transactions. As of July 2015, the current focus was [https://github.com/bitcoin/bips/pull/163 BIP101].

==== What was the major advantage of this proposal? ====

''Bitcoin can support many more users.'' Assuming earliest possible adoption, 250 bytes per on-chain transaction, 144 blocks per day, and 2 transaction a day per user, Bitcoin can support about,

* 288,000 users in 2015
* 2,304,000 users in 2016 (800% increase)
* 4,608,000 in 2018 (1,600%)
* 9,216,000 in 2020 (3,200%)
* 18,432,000 in 2022 (6,400%)
* 36,864,000 in 2024 (12,800%)
* 73,728,000 in 2026 (25,600%)
* 147,456,000 in 2028 (51,200%)
* 294,912,000 in 2030 (102,400%)
* 589,824,000 in 2032 (204,800%)
* 1,179,648,000 in 2034 (409,600%
* 2,359,296,000 in 2036 (819,200%)

==== What is the major disadvantage of this proposal? ====

''The total cost of remaining decentralized will be high.'' Assuming earliest possible adoption and that the ratio of total users to full node operators remains the same as today, the total estimated amount of work necessary to maintain the decentralized system under the [[#O.28n2.29_network_total_validation_resource_requirements|O(2) scaling model]] will be,

* 100% of today’s work in 2015
* 6,400% in 2016
* 25,600% in 2018
* 102,400% in 2020
* 409,600% in 2022
* 1,638,400% in 2024
* 6,553,600% in 2026
* 26,214,400% in 2028
* 104,857,600% in 2030
* 419,430,400% in 2032
* 1,677,721,600% in 2034
* 6,710,886,400% in 2036

For example, if the total amount spent on running full nodes today (not counting mining) is $100 thousand per year, the estimated cost for the same level of decentralization in 2036 will be $6.7 trillion per year if validation costs stay the same. (They'll certainly go down, but algorithmic and hardware improvements probably won't eliminate an approximate 6,710,886,400% cost increase.)

==== What are the dangers of the proposed hard fork? ====

Under the then-current current proposal, 75% of miners must indicate that they agree to accept blocks up to 8 MB in size.<ref name="bip101">[https://github.com/bitcoin/bips/pull/163 BIP101], Gavin Andresen, 24 June 2016</ref> After the change goes into effect, if any miner creates a block larger than 1 MB, all nodes which have not upgraded yet will reject the block.<ref>[https://bitcoin.org/en/developer-guide#consensus-rule-changes Consensus rule changes], Bitcoin.org Developer Guide</ref>

If all full nodes have upgraded, or very close to all nodes, there should be no practical effect. If a significant number of full nodes have not upgraded, they will continue using a different block chain than the upgraded users, with the following consequences:

* Bitcoins received from before the fork can be spent twice, once on both sides of the fork. This creates a high double spend risk.
* Bitcoins received after the fork are only guaranteed to be spendable on the side of the fork they were received on. This means some users will have to lose money to restore Bitcoin to a single chain.

Users of hosted wallets (Coinbase, BlockChain.info, etc.) will use whatever block chain their host chooses. Users of lightweight P2P SPV wallets will use the [[Thin Client Security|longest chain they know of]], which may not be the actual longest chain if they only connect to nodes on the shorter chain. Users of non-P2P SPV wallets, like Electrum, will use whatever chain is used by the server they connect to.

If a bad hard fork like this happens, it will likely cause large-scale confusion and make Bitcoin very hard to use until the situation is resolved.

==== What is the deployment schedule for BIP 101? ====

* The patch needs to be accepted into Bitcoin Core, Bitcoin XT, or both.
* If accepted into Bitcoin Core, miners using that software will need to upgrade (this probably requires a new released version of Bitcoin Core). If accepted only into Bitcoin XT, miners will need to switch to using XT.
* After 75% of miners have upgraded, 8MB blocks will become allowed at the the latest of (1) 11 January 2016 or (2) two weeks after the 75% upgrade threshold.<ref name="bip101" />
* After the effective date has passed, any miner may create a block larger than 8MB. When a miner does this, upgraded full nodes will accept that block and non-upgraded full nodes will reject it, forking the network.<ref name="bip101" /> See [[#What_are_the_dangers_of_the_proposed_hard_fork.3F|hard fork dangers]] for what his might mean.

==== Will miners go straight from 1 MB blocks to 8 MB blocks? ====

That would be highly unlikely. Uploading an 8 MB block currently takes significantly more time than uploading a 1 MB block<ref name="rusty_dsl">[http://rusty.ozlabs.org/?p=509 Mining on a home DSL connection test results], Rusty Russell, 19 June 2015</ref>, even with the roughly 25x reduction in size available from use of Matt Corallo’s block relay network.<ref name="block_relay_net" />

The longer it takes to upload a block, the higher the risk it will become a stale block—meaning the miner who created it will not receive the block subsidy or transaction fees (currently about 25 BTC per block).

However, if technology like Invertible Bloom Lookup Tables (IBLTs) is deployed and found to work as expected<ref name="iblt">[https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2 O(1) block propagation], Gavin Andresen, 8 August 2014</ref>, or if mining [[#What_is_the_most_efficient_way_to_scale_Bitcoin.3F|centralizes further]], adding additional transactions may not have a significant enough cost to discourage miners from creating full blocks. In that case, blocks will be filled as soon as there are enough people wanting to make transactions paying the default relay fee<ref>[https://github.com/bitcoin/bitcoin/pull/3305 Bitcoin Core pull #3305 dropping default fees], Mike Hearn, 22 November 2013</ref> of 0.00001000 BTC/kilobyte.

==== What tests have been performed related to this proposal? ====

* '''20MB block processing''' (Gavin Andresen) “if we increased the maximum block size to 20 megabytes tomorrow, and every single miner decided to start creating 20MB blocks and there was a sudden increase in the number of transactions on the network to fill up those blocks… the 0.10.0 version of [Bitcoin Core] would run just fine.”<ref>[http://gavintech.blogspot.com/2015/01/twenty-megabytes-testing-results.html Twenty megabyte block testing], Gavin Andresen, 20 January 2015</ref> (ellipses in original)
* '''Mining & relay simulation''' (Gavin Andresen) “if blocks take 20 seconds to propagate, a network with a miner that has 30% of the hashing power will get 30.3% of the blocks.”<ref>[http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners Are bigger blocks better for bigger miners?], Gavin Andresen, 22 May 2015</ref>
* '''Mining on a home DSL connection''' (Rusty Russell) “Using the rough formula of 1-exp(-t/600), I would expect orphan rates of 10.5% generating 1MB blocks, and 56.6% with 8MB blocks; that’s a huge cut in expected profits.”<ref name="rusty_dsl" />
* '''Mining centralization pressure''' (Pieter Wuille) “[This] does very clearly show the effects of larger blocks on centralization pressure of the system.”<ref name="wuille_centralization">[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008581.html Mining centralization pressure from non-uniform propagation speed], Pieter Wuille, 12 June 2015</ref>

=== Garzik Miner Block Size Voting Proposal (AKA BIP100) ===

''Note, BIP 100 is the marketing name for this proposal. No BIP number
has yet been publicly requested, and the number assigned is unlikely to
be 100.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-May/005756.html
Prenumbered BIP naming], Gregory Maxwell, 12 May 2014</ref>''

Questions related to Jeff Garzik's proposal<ref name="garzik_bip">[http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf Draft BIP: decentralized economic policy], Jeff Garzik, 12 June 2015 (revised 15 June 2015)</ref> to allow miners to vote on raising and lowering the maximum block size.

==== What does this proposal do? ====

# It creates a one-time hard fork that does not automatically change the maximum block size.

# It allows miners to vote to increase or decrease the maximum block size within the range of 1MB to 32MB. These changes are neither hard forks nor soft forks, but simply rules that all nodes should know about after the initial hard fork.

==== Does it reduce the risk of a hard fork? ====

Hard forks are most dangerous when they're done without strong
consensus.<ref name="garzik_bip" /><ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008779.html Consensus changes are not about making a change to the software],
Pieter Wuille, 18 June 2015</ref>

If Garzik's proposal gains strong consensus, it will be as safe as possible
for a hard fork and it will allow increasing the block size up to 32 MB
without any additional risk of a fork.

==== Why is it limited to 32 megabytes? ====

According to the draft BIP, "the 32 MB hard fork is largely coincidental -- a whole network upgrade at 32 MB was likely needed anyway."

=== Lightning Network ===

Questions related to using the proposed [http://lightning.network/ Lightning network] as a way to scale the number of users Bitcoin can support.

==== How does transaction security differ from that of Bitcoin? ====

Transactions on the proposed Lightning network use Bitcoin transactions exclusively to transfer bitcoins<ref name="russell_lightning1">[http://rusty.ozlabs.org/?p=450 Lightning Networks: Part I], Rusty Russell, 30 March 2015</ref>, and so the same security as regular Bitcoin transactions is provided when both a Lightning hub and client are cooperating.

When a Lightning hub or client refuses to cooperate with the other (maybe because they accidentally went offline), the other party can still receive their full 100% bitcoin balance by closing the payment channel—but they must first wait for a defined amount of time mutually chosen by both the hub and client.<ref>[http://rusty.ozlabs.org/?p=462 Lightning Networks: Part II], Rusty Russell, 1 April 2015</ref>

If one party waits too long to close the payment channel, the other party may be able to steal bitcoins. However, it is possible to delegate the task of closing the channel in an emergency to an unlimited number of hubs around the Internet, so closing the channel on time should be easy.<ref name="russell_lightning4">[http://rusty.ozlabs.org/?p=477 Lightning Networks: Part IV], Rusty Russell, 8 April 2015</ref>

In summary, provided that payment channels are closed on time, the worst that can happen to users is that they may have to wait a few weeks for a channel to fully close before spending the bitcoins they received from it. Their security is otherwise the same as with regular Bitcoin.

For Lightning hubs, security is slightly worse in the sense that they need to keep a potentially-large amount of funds in a hot wallet<ref name="lightning_paper">[http://lightning.network/lightning-network-paper-DRAFT-0.5.pdf Lightning Network (Draft 0.5)], Section 6.3: Coin Theft via Hacking, Joseph Poon and Thaddeus Dryja</ref>, so they can’t take advantage of the anti-hacking protection offered by cold wallets. Otherwise, Lightning hubs have the same security as clients.

==== When will Lightning be ready for use? ====

Lightning requires a basic test implementation (work underway<ref>[https://lists.blockstream.com/pipermail/lightning-dev/2015-June/000018.html Lightning first steps], Rusty Russell, 13 June 2015</ref>), several soft-fork changes to the Bitcoin protocol (work underway<ref>[https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65: CheckLockTimeVerify], Peter Todd, 1 October 2014</ref><ref>[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68: Consensus-enforced transaction replacement], Mark Friedenbach, 28 May 2015</ref>, and wallets need to be updated to support the Lightning network protocol.<ref name="russell_lightning4" />

Dr. Adam Back has said, "I expect we can get something running inside a year."<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009242.html Reply to Andresen regarding Lightning], Dr. Adam Back, 28 June 2015</ref>

==== Doesn’t Lightning require bigger blocks anyway? ====

Lightning is block-size neutral. It requires one on-chain transaction to open a channel between a hub and a client, and one on-chain transaction to close a channel.<ref name="russell_lightning1" /> In between it can support an unlimited number of transactions between anyone on the Lightning network.<ref name="lightning_paper" />

Using the numbers from the Lightning presentation<ref name="lightning_slides">[http://lightning.network/lightning-network.pdf Lightning presentation], Joseph Poon, 23 February 2015</ref>, if people open and close a plausible two channels a year, Lightning can support about 52 million users with the current one-megabyte limit—and each user can make an unlimited number of transactions. Currently, assuming people make an average of only two Bitcoin transactions a day, basic Bitcoin can support only 288,000 users.

Under these assumptions, Lightning is 180 times (17,900%) more efficient than basic Bitcoin.

Presumably, if around 30 million people are using Bitcoin via Lightning so that capacity is called into question, it will not be difficult to find consensus to double the block size to two megabytes and bring user capacity up to 105 million. The same goes for later increases to 200 million (4MB), 400 million (8MB), 800 million (16MB), 1.6 billion (32 MB), 3.2 billion (64MB), and all 7 billion living humans (133MB). In each case, all Lightning network participants get unlimited transactions to the other participants.

For basic Bitcoin to scale to just 2 transactions a day for 7 billion people would require 24-gigabyte blocks.<ref name="lightning_slides" />

=== Sidechains ===

==== Real quick, what are sidechains? ====

Block chains that are separate from Bitcoin’s block chain, but which allow you to receive and spend bitcoins using a two-way peg (2WP).<ref name="sidechains_paper">[https://www.blockstream.com/sidechains.pdf Sidechains paper], Adam Back et al., 22 October 2014</ref> (Although a sidechain can never be more secure than the Bitcoin block chain.<ref>[https://www.reddit.com/r/Bitcoin/comments/39r85g/sidechain_hate/cs5spbg Security limitations of pegged chains], Gregory Maxwell, 14 June 2015</ref>)

==== Are sidechains a scaling option? ====

No. Sidechains have the same fundamental scaling problems as Bitcoin does. Moving some transactions to sidechains simply moves some problems elsewhere on the network—the total difficulty of the problem remains the same.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008617.html Sidechains not a direct means for solving any of the scaling problems Bitcoin has], Pieter Wuille, 13 June 2015</ref>

==== But couldn’t I create a sidechain that had 100 GB blocks? ====

Certainly, sidechain code is open source<ref>[https://github.com/ElementsProject/elements Elements Project]</ref>—so you can create your own sidechain. But you’d still have the difficulty of finding people who are willing to validate 100 GB blocks with their own full nodes.

==== Do sidechains require a hard fork? ====

No. Federated sidechains, such as have already been implemented<ref>[https://github.com/ElementsProject/elements/tree/alpha Elements Alpha]</ref>, don’t require any changes to the Bitcoin consensus rules. Merged-mined sidechains, which have not been implemented yet, do require a backwards-compatible soft fork in order to transfer funds between Bitcoin and the sidechain.<ref name="sidechains_paper" />

== References ==
<references />

Mushino

2020-05-18T01:52:21Z

Midnightmagic: Protected "Mushino": page likely to be deleted soon as it is impossible for us to vet commercial enterprise for inclusion on the wiki ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite)) [cascading]

[https://mushino.com Mushino] is a bitcoin futures platform. Users can go long or short on a wide variety of bitcoin-settled futures contracts.

The service features a unique ladder interface that has become particularly popular among scalpers and daytraders.

== '''Services''' ==

=== '''Go long on Bitcoin''' ===

Mushino allows users to take a [https://mushino.com/pair?pair=BTC_USD_PERP long position on bitcoin]. Users can do so by depositing bitcoins to their personal deposit address. A deposit usually takes less than 20 minutes to complete, making the platform much faster to get started with than futures platforms in traditional finance. Users may also claim a [https://mushino.com/bonus $2 welcome bonus] that will allow them to get started instantly.

Once the deposit has been completed, a long position can be opened. This is done by submitting a ''long'' order, and having the order filled in the market. Once filled, the user will have an open long position. The user will then profit if bitcoin rises in value compared to the US dollar. If bitcoin loses value compared to the US dollar, the user will lose money instead.

=== '''Go short on Bitcoin''' ===

To go short on Bitcoin, the user simply needs to submit a ''short'' order instead. Once the order has been filled, the user will have a short position.

=== '''Closing a position''' ===

Once the user wants to exit his position, the user submits a ''close'' order. Once the order is filled, the user's position is considered closed. All profits from the position are then credited to the user's balance. The user may then withdraw any profits that he made, or use them to open a new position.

=== '''Using Bitcoin to go long or short on altcoins''' ===

Using Mushino's [https://mushino.com/funding?key=about_the_pair&pair=USDT_ALTS_PERP index futures], the user may also go long or short on altcoins.

An '''index''' on Mushino is a collection of altcoins. The user may go either long or short on this index. This way the user will be long or short on multiple altcoins at once, diversifying the portfolio of the user.

== '''Trading interface''' ==

The order books on Mushino are built like ladders. This type of interface is extremely popular among scalpers and daytraders, as it lets them submit and cancel orders very quickly.

To submit an order on Mushino, traders click somewhere on the ladder.

If the trader clicks on the left side of the ladder, the trader submits a ''long'' order.

If the trader clicks on the right side of the ladder, the trader submits a ''short'' order.

If the trader clicks in the middle of the ladder, the trader submits a 'close'' order.

Mushino has support for custom order quantities, order types and keyboard shortcuts.

The Mushino Position Editor allows traders to edit their stop loss and take profit in real time.

== '''Margin''' ==

When the user places an order for the purpose of opening a new position, the user sets aside a certain amount of bitcoin as margin. The margin can be thought of as a security deposit - the purpose of it is to ensure that the user cannot just withdraw all of his bitcoin and then run away, in the case that the price moves against him. The user has the freedom to choose the amount of margin that he wants to set aside for the position, given that he sets aside an amount that is equivalent to at least 0.67 percent of the size of his position. The relationship between the chosen amount of margin and the size of the position is known as [https://www.investopedia.com/terms/l/leverage.asp leverage]. Mushino supports up to 150x leverage, giving the user the option to open a position with a size that is up to 150 times greater than the amount of margin deposited. The use of leverage is entirely optional. The user may choose to use 1x leverage - in that case he will have to set aside enough margin to cover the entire size of the position.

=== '''Limited liability''' ===

Mushino operates with a concept called isolated margin. Isolated margin ensures that the user can never lose more than what he puts in as margin. He will never end up in a situation where he has a negative balance, or owes the platform money. If the price moves rapidly against the user, and the user's margin cannot cover the loss, the user's position is [https://support.mushino.com/hc/en-us/articles/360002543017-What-happens-if-I-get-liquidated- liquidated]. Once liquidated, the position will be reduced in size by 10% or $10000 (whichever is greater). In some cases, the position will be closed entirely. In those cases, the user is able to open a new position immediately afterwards. All profits that may arise from selling off a part of the user's position are credited to the balance of the user.

== '''Security''' ==

Mushino stores more than 99.9% of their users' bitcoins in geographically distributed multisignature cold wallets. Geographically distributed multisignature cold wallets are extremely hard to compromise, as they require attackers to simultaneously compromise multiple physical locations, in multiple different parts of the world.

The platform is engineered to be solvent at all times - if the platform becomes even 0.001% insolvent, the platform will shut down automatically.

Advanced security features such as Two Factor Authentication (2FA), Device Whitelisting, Withdrawal Limits and IP Pinning are utilized to protect the user's account from ever being compromised.

== '''See Also''' ==

[[Deribit|Deribit]]

== '''External Links''' ==

[https://mushino.com Mushino.com] website

[[Category:Exchanges]] [[Category:Futures Exchanges]] [[Category:Investing]] [[Category:Financial]] [[Category:Stock Exchanges]] [[Category:Bonds Markets]]

Skyroad

2020-05-18T01:50:19Z

Midnightmagic: Protected "Skyroad": page likely to be deleted soon as primarily off-topic ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite)) [cascading]

{{infobox company|name=Skyroad|image=[[File:Skyroad.png]]
|foundation=August 06, 2011
|owner=Immanuel94
|website=https://www.skyroad.me
}}'''Skyroad''' is a Minecraft Server with multible Game Modes.

The Server has its own economy called Taler it does no longer allow players to payout their ingame currency. At the moment, players can participate at contests to earn rewards (cryptocurrency) for their contribution. News about these contests can be found at the blog of the server operator: https://hive.blog/@immanuel94/posts.

Server IP: join.skyroad.me

==Voting==
The server is listed in a Minecraft Serverlist<ref>http://vote.skyroad.me</ref> and can get on the top of the List for votes. 
To Vote, use the Command /help at the Spawnpoint of the Server and click on the chat message "[Voten]", after that, navigate to "Jetzt voten" and get the Money.

[[Category:Games]]

=References=

<references/>

User talk:Mikemolleux

2020-05-18T01:48:28Z

Midnightmagic: Created page with "Hello. I am going to delete that futures service page, as the service is new, not particularly notable, and has not proven itself as a reliable and honest commercial enterpris..."

Hello. I am going to delete that futures service page, as the service is new, not particularly notable, and has not proven itself as a reliable and honest commercial enterprise. I mean. Most haven't, but in particular, new commercial services due to the extreme amount of scamming in general are not something .. basically any of us are willing to vet for inclusion on the wiki. So. I'm going to delete this page soon. If you can think of a reason why I shouldn't, please let me know. [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 01:48, 18 May 2020 (UTC)

Segwit support

2018-12-17T12:53:49Z

Midnightmagic: Reverted edits by Harmaty (talk) to last revision by MeshCollider

<big><big>'''PLEASE NOTE:''' This list is not yet complete.</big></big>

'''Developers/businesses: Please add a row for yourself in the applicable table to reflect your positions. If for some reason you don't already have a wiki account that can edit the page, make an account and ask luke-jr for help if you get caught in the anti-spam.'''

{| class="wikitable"
| {{No}} || doesn't support (but might or might not go along with it with sufficient community support)
|-
| {{Deficient}} || okay with the idea, but considers it to have insufficient community support
|-
| {{Evaluating}} || still evaluating the idea
|-
| {{AccJuly}} || it is a workable solution, provided it is activated before August 1 (and therefore BIP148-compatible)
|-
| {{Wanting}} || positively likes the idea, but considers it to have insufficient community support
|-
| {{Weak}} || better than nothing at all
|-
| {{Acceptable}} || it is a workable solution
|-
| {{Prefer}} || it is what he would choose if it was only up to him and no outside influences
|}

__TOC__

==Developers==



''Note that support for a given proposal does not mean developers support merging it into Core or any other specific codebase.''

{| class="wikitable sortable"
! rowspan=2 | Developer
! rowspan=2 | Aff* 
! Segwit itself
! colspan=3 | Deployment methods
! colspan=2 | Hardfork bundles (Silbert agreement)
|-
! [https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP 141] !! [https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki BIP 148] !! [https://github.com/bitcoin/bips/blob/master/bip-0149.mediawiki BIP 149] !! [https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki BIP 91] || Segwit2x || [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014445.html COOP]
|-
| Karl-Johan Alm || Core || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}}
|-
| Bryan Bishop || || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{Weak}} || {{No}} || {{No}}
|-
| Edmund Broadley || Core || {{Acceptable}} || {{No}} || {{No}} || {{AccJuly|AccJuly}} || {{No}} || {{Evaluating}}
|-
| ฿tcDrak || Core || {{Prefer}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}} || {{No}}
|-
| Andrew Chow || Core || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Weak}} || {{No}} || {{No}}
|-
| Wang Chun || [[F2Pool]] || {{Prefer}} || {{Acceptable}} || {{Acceptable}} || {{Acceptable}} || {{AccJuly}} ||
|-
| Matt Corallo || Core || {{Prefer}} || {{No}} || || {{Acceptable}} || {{No|LOL}} ||
|-
| Johnathan Corgan || Core || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{No}} || {{No}} || {{No}}
|-
| Luke Dashjr || Core || {{Prefer}} || {{Prefer}} || {{No}} || {{AccJuly}} || {{No}} || {{Deficient}}
|-
| Christian Decker || c-lightning || {{Prefer}} || {{Acceptable}} || || || {{No}} || {{No}}
|-
| Samuel Dobson || Core || {{Prefer}} || || || || {{No}} ||
|-
| Nicolas Dorier || Core || {{Prefer}} || {{Deficient}} || {{Acceptable}} || {{AccJuly}} || ||
|-
| Thaddeus Dryja || lit || {{Prefer}} || {{No}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}}
|-

| Mark Friedenbach || BIP 68/112 || {{Prefer}} || {{Prefer}} || {{No}} || {{AccJuly}} || {{No|LOL}} || {{No|Nope}}
|-
| Pavel Janik || Core || {{Prefer}} || {{No}} || {{Acceptable}} || {{No}} || {{No}} || {{No}}
|-
| Thomas Kerin || Core || {{Prefer}} || {{Wanting}} || {{Prefer}} || {{Weak}} || {{No}} || {{No}}
|-
| Johnson Lau || Core || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}}
|-
| Eric Lombrozo || || {{Prefer}} || {{Acceptable}} || {{Weak}} || {{AccJuly}} || {{No}} || {{No}}
|-
| Greg Maxwell || Core || {{Prefer}} || {{Deficient}} || {{Acceptable}} || {{Weak}} || {{No}} || {{No}}
|-
| Alex Morcos || Core || {{Prefer}} || {{Deficient}} || {{Acceptable}} || {{Weak}} || {{No}} ||
|-
| nopara73 || TumbleBit || {{Weak}} || {{Wanting}} || {{Prefer}} || || {{No}} ||
|-
| Laolu "roasbeef" Osuntokun || lnd || {{Prefer}} || || || || {{No}} ||
|-
| Kristofer "rawlzsec" Rawlins || || {{Prefer}} || {{Acceptable}} || {{Weak}} || {{AccJuly}} || {{No}} || {{No}}
|-
| Jeremy Rubin || Core || {{Prefer}} || {{Deficient}} || {{No}} || {{AccJuly}} || {{No}} || {{No}}
|-
| Pavol "stick" Rusnak || [[TREZOR]] || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{AccJuly}} || {{No}} || {{No}}
|-
| Rusty Russell || c-lightning || {{Prefer}} || {{Prefer}} || || || ||
|-
| Gregory Sanders || Core || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{Weak}} || {{No}} ||
|-
| Jonas Schnelli || Core || {{Prefer}} || {{Wanting}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}}
|-
| Patrick Strateman || Core || {{Prefer}} || || || || {{No}} || {{No}}
|-
| Paul Sztorc || || {{Prefer}} || {{Deficient}} || {{Wanting}} || {{AccJuly}} || {{No}} || {{No}}
|-
| Amir Taaki || libbtc || {{Acceptable}} || {{Prefer}} || || || {{No}} || {{No}}
|-
| Jorge Timon || Core || {{Prefer}} || {{No}} || {{Prefer}} || {{Deficient}} || {{No}} || {{No}}
|-
| Peter Todd || || {{Prefer}} || {{Deficient}} || {{Wanting}} || {{AccJuly}} || {{No|LOL}} ||
|-
| Warren Togami || Elements || {{Prefer}} || {{Prefer}} || {{Acceptable}} || || ||
|-
| Wladimir van der Laan || Core || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}}
|-
| Thomas Voegtlin || Electrum || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Acceptable}} || {{No}} || {{No}}
|-
| Leo Wandersleb || Mycelium || {{Prefer}} || {{Prefer}} || {{Acceptable}} || {{Weak}} || {{No}} || {{No}}
|-
| Pieter Wuille || Core || {{Prefer}} || || || || {{No}} ||
|}

* "affiliation" is an optional field for the company or project the individual is associated with, that most qualifies the person to comment on the matter and is not meant as a company or project endorsement of the individual's position.

==Businesses==

'''When adding companies below, sources for each position MUST be provided.'''

{| class="wikitable sortable"
! rowspan=2 | Company
! rowspan=2 | Service
! Segwit itself
! colspan=3 | Deployment methods
! colspan=2 | Hardfork bundles (Silbert agreement)
|-
! [https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP 141] !! [https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki BIP 148] !! [https://github.com/bitcoin/bips/blob/master/bip-0149.mediawiki BIP 149] !! [https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki BIP 91] || Segwit2x || [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014445.html COOP]
|-
| Abra || wallet || {{Prefer}}<ref name="coindance" /> || {{Prefer}}<ref name="coindance" /> || || {{AccJuly}} || {{AccJuly}}<ref name="silbert" /> ||
|-
| Bitcoin India || exchange/miner || {{Prefer}}<ref name="coindance" /> || {{Prefer}}<ref name="coindance" /> || || || ||
|-
| BitcoinReminder.com || service || {{Prefer}}<ref name="bitcoinreminder_com">[https://bitcoinreminder.com/informations/poli BitcoinReminder.com's position on scaling proposals]</ref> || {{Prefer}}<ref name="bitcoinreminder_com"/> || {{Acceptable}}<ref name="bitcoinreminder_com"/> || {{Weak}}<ref name="bitcoinreminder_com"/> || {{No|LOL}}<ref name="bitcoinreminder_com"/> || {{No}}<ref name="bitcoinreminder_com"/>
|-
| Bitfinex || exchange || {{Acceptable}}<ref name="coindance" /> || {{Acceptable}} || || || ||
|-
| Bitfury || miner || {{Prefer}}<ref name="coindance" /> || {{Acceptable}} || || {{AccJuly}} || {{AccJuly}}<ref name="silbert" /> ||
|-
| Bitmain || miner || {{AccJuly}}<ref name="bitmain">[https://blog.bitmain.com/en/uahf-contingency-plan-uasf-bip148/ Bitmain's plot against BIP148]</ref> || {{No}} || || {{AccJuly}} || {{AccJuly}}<ref name="bitmain" /> ||
|-
| Bitonic/BL3P.eu || exchange || {{Prefer}}<ref name="bitonic">[https://bitonic.nl/en/news/138/our-position-on-scaling-proposals Bitonic's position on scaling proposals]</ref> || {{Prefer}}<ref name="bitonic"/> || {{Acceptable}}<ref name="bitonic"/> || {{Weak}}<ref name="bitonic"/> || {{No|LOL}}<ref name="bitonic"/> || {{No}}
|-
| Bitpay || wallet || {{Prefer}}<ref name="bccore_swadoption"/> || {{No}} || || {{Prefer}} || {{Prefer}}<ref name="silbert" /> ||
|-
| Bitrated || reputation || {{Acceptable}}<ref name="bitrated">[https://twitter.com/bitrated/status/876805892003553281]</ref> || {{Acceptable}}<ref name="bitrated" /> || {{Prefer}}<ref name="bitrated" /> || {{AccJuly}}<ref name="bitrated" /> || {{No}}<ref name="bitrated" /><ref>[https://medium.com/@shesek/why-i-dont-support-the-compromise-efforts-9d73a8cce6be Why I don’t support horse-trading compromises for Bitcoin protocol development]</ref> ||
|-
| Bitrefill || merchant || {{Prefer}}<ref name="coindance" /> || {{Prefer}}<ref name="coindance" /> || || || ||
|-
| Bitsquare || exchange || {{Prefer}} || {{Prefer}}<ref name="bitsquare">[https://forum.bitsquare.io/t/bitsquare-will-support-uasf-bitcoin-not-bitmaincoin/2265 Bitsquare will support UASF Bitcoin not BitMainCoin]</ref> || {{Acceptable}}<ref name="bitsquare"/> || || ||
|-
| Bitstamp || exchange || || || || || ||
|-
| Bittylicious || exchange || {{Prefer}}<ref name="coindance" /> || {{Prefer}}<ref>[https://twitter.com/Bittylicious_/status/867305106668224513 Bittylicious answer on Twitter]</ref> || || || ||
|-
| Blockchain.info || wallet || {{Acceptable}}<ref name="bccore_swadoption"/> || || || {{AccJuly}} || {{AccJuly}}<ref name="silbert" /> ||
|-
| blockonomics || || {{Prefer}} || {{Prefer}}<ref>[https://twitter.com/blockonomics_co/status/851738251509497856 blockonomics announcement on Twitter]</ref> || || || ||
|-
| Bustabit|| gambling || {{Prefer}}<ref name="bustabit">[https://www.bustabit.com/statement-on-forks Bustabit Statement on Bitcoin Forks]</ref> || {{Acceptable}}<ref name="bustabit"/> || || || {{AccJuly}}<ref name="bustabit"/> ||
|-
| Bylls || payments / exchange || {{Prefer}}<ref name="bylls">[https://twitter.com/myBylls/status/877959773794316288 Bylls supports Segwit softfork but no current HF plan]</ref> || {{Prefer}}<ref name="bylls">[https://twitter.com/myBylls/status/877959773794316288 Bylls supports Segwit softfork but no current HF plan]</ref> || {{Acceptable}}<ref name="bylls">[https://twitter.com/myBylls/status/877965277316730880 Bylls twitter statement]</ref> || {{AccJuly}}<ref name="bylls">[https://twitter.com/myBylls/status/877965277316730880 Bylls twitter statement]</ref> || {{No}}<ref name="bylls">[https://twitter.com/myBylls/status/877965277316730880 Bylls twitter statement]</ref> || {{No}}<ref name="bylls">[https://twitter.com/myBylls/status/877965277316730880 Bylls twitter statement]</ref>
|-
| Ciphrex || wallet / dev stack || {{Prefer}}<ref name="coindance" /> || {{Acceptable}}<ref name="coindance" /> || || || ||
|-
| Coinbase || wallet || {{Acceptable}}<ref name="bccore_swadoption"/> || || || {{AccJuly}} || {{AccJuly}}<ref name="silbert" /> ||
|-
| CoinGate || exchange || {{Prefer}}<ref name="coindance" /> || {{Prefer}}<ref name="coindance" /> || || || ||
|-
| CoinJar || wallet || || {{Evaluating}}<ref>[https://twitter.com/GetCoinJar/status/875581525730787329 CoinJar answer on Twitter]</ref> || || || ||
|-
| Coinkite || || {{Prefer}}<ref name="coindance" /> || {{Prefer}}<ref name="coindance" /> || || || ||
|-
| coinomi || wallet || {{Prefer}}<ref name="coindance" /> || {{Prefer}}<ref name="coindance" /> || || || ||
|-
| DigitalBitbox || wallet(hardware) || {{Prefer}} || {{Acceptable}} || {{Prefer}}|| || ||
|-
| Échange de Montréal || exchange || {{Prefer}}<ref name="echangedemontreal" /> || {{Prefer}}<ref name="echangedemontreal" /> || || ||
|-
| Jaxx || || {{Prefer}}<ref name="jaxx">[https://twitter.com/Jaxx_Support/status/882607648457334785 Jaxx tweet]</ref> || {{Acceptable}}<ref name="jaxx"/> || || {{AccJuly}}<ref name="jaxx"/> || {{AccJuly}}<ref name="jaxx"/> ||
|-
| Kraken || exchange || || || || || ||
|-
| LightningASIC || miner || {{Prefer}}<ref name="coindance" /> || {{Prefer}}<ref name="coindance" /> || || || ||
|-
| OneHash || betting || {{Prefer}}<ref>[https://blog.onehash.com/sick-of-presidential-election-3f1a2defbbbf OneHash, "Sick of presidential election ?!"]</ref> || || || {{AccJuly}} || {{AccJuly}}<ref name="silbert" /> ||
|-
| Poloniex || exchange || || || || || ||
|-
|QUOINE || exchange, trading, financial services || {{Evaluating}}<ref name="coindance" /> || {{Evaluating}}<ref name="coindance" /> || {{Evaluating}}<ref name="coindance" /> || {{Evaluating}}<ref name="coindance" /> || {{Evaluating}}<ref name="coindance" /> || {{Evaluating}}<ref name="coindance" />
|-
| SimpleFX || broker, financial services || {{Prefer}}<ref name="bccore_swadoption"/> || {{Prefer}}<ref name="bccore_swadoption"/> || || || ||
|-
| Slushpool || miner || {{Prefer}}<ref name="coindance" /> || {{Acceptable}}<ref name="coindance" /> || || || ||
|-
| TheRockTrading || exchange || || {{Evaluating}}<ref>[https://twitter.com/TheRockTrading/status/872464394034315269 @TheRockTrading message on Twitter]</ref> || || || ||
|-
| Vaultoro || exchange || {{Prefer}}<ref name="coindance" /> || {{Acceptable}}<ref name="coindance" /> || || {{AccJuly}} || {{AccJuly}}<ref name="silbert" /> ||
|-
| Walltime || exchange || {{Prefer}}<ref name="coindance" /> || {{Prefer}}<ref name="coindance" /> || || || ||
|-
| Woleet || Timestamping || {{Prefer}}<ref name="woleet">[https://twitter.com/Woleet/status/884078514307297280]</ref> || {{Prefer}}<ref name="woleet">[https://twitter.com/Woleet/status/884078514307297280]</ref>|| || || ||
|-
| Xapo || wallet || {{Prefer}}<ref name="coindance" /> || || || {{AccJuly}}<ref name="xapo">[https://twitter.com/tedmrogers/status/883061218545614848 Xapo tweet]</ref> || {{AccJuly}}<ref name="xapo"/> ||
|-
|}

<references>
<ref name="bccore_swadoption">[https://bitcoincore.org/en/segwit_adoption/ Bitcoin Core's Segwit adoption list]</ref>
<ref name="coindance">[https://coin.dance/poli Coin Dance, "Global Bitcoin Political Support & Public Opinion"]</ref>
<ref name="silbert">[https://medium.com/@DCGco/bitcoin-scaling-agreement-at-consensus-2017-133521fe9a77 Digital Currency Group, "Bitcoin Scaling Agreement at Consensus 2017"]</ref>
<ref name="echangedemontreal">[https://twitter.com/echangedemtl/status/875781093261271040 Échange de Montréal on twitter]</ref>
</references>

Bitcoinfactswiki

2018-07-02T01:23:20Z

Midnightmagic: the bitcoinfactswiki seems to be dead.

== Historical Note Only ==

The BitcoinFactsWiki has been removed from its original location; Tom Zander being its originator has resigned from the -classic project and this resignation is likely reflected in the removal of projects like the BitcoinFactsWiki.

== An Unusual Fork ==
The website represented by [http://bitocinfactswiki.github.io The Bitcoinfactswiki] and announced in the Reddit story from its apparent creator [https://www.reddit.com/r/btc/comments/4n44oi/bitcoin_wiki_renamed_to_bitcoinfactswiki here] is not actually a "renamed" version of this site, but a plain fork, contrary to the claims in that story. The person behind it, Thomas Zander, is the (apparently only remaining,) developer of Bitcoin Classic.

The facts on Bitcoinfactswiki are in multiple cases wrong and the information thereon regarding technical information about Bitcoin appears to be politically-motivated and -edited. For example, as of this writing the page [https://bitcoinfactswiki.github.io/NLockTime/ on Bitcoinfactswiki about nLockTime] states:
<blockquote>
'''This tag is deprecated and OP CHECKLOCKTIMEVERIFY is the suggested replacement.'''
</blockquote>
This is incorrect. nLockTime is not deprecated nor is it insecure.<ref>[https://www.reddit.com/r/btc/comments/4uv21m/announcing_blockstreams_greenaddress_acquisition/d5t9rm8 Greg Maxwell stating clearly thet nLockTime is alive and well.]</ref>

It is likely that due to the obstacle that nLockTime presents to the hard-forking narrative, it is being downplayed as a technical objection and stated to be a deprecated function even though it has been an integral part of Bitcoin transaction structure almost from Bitcoin's inception. In particular, nLockTime (or lock_time based transactions) can be used as a form of escrow. In the event of certain forms of advocated hard forks, the result would be the confiscation and/or destruction of nLockTime based escrowed funds.
== References ==
<references/>

Controlled supply

2018-04-26T16:27:57Z

Midnightmagic: correction?

<blockquote>A fixed money supply, or a supply altered only in accord with objective and calculable criteria, is a necessary condition to a meaningful just price of money.<ref>[https://isidore.co/calibre/browse/book/5277 Interest and Usury] p. 220 by [https://www.jstor.org/stable/29769582 Fr. Bernard W. Dempsey, S.J.] (1903-1960); cf. John Horvat II [https://isidore.co/calibre/browse/book/5155 Return to Order] ch. 37 "The Backing of Money"</ref>
—[https://www.jstor.org/stable/29769582 Fr. Bernard W. Dempsey, S.J.] (1903-1960)</blockquote>

In a centralized economy, currency is issued by a central bank at a rate that is supposed to match the growth of the amount of goods that are exchanged so that these goods can be traded with stable prices. The
[[wikipedia:monetary base|monetary base]] is controlled by a central bank. In the United States, the [[wikipedia:Federal Reserve System|Fed]] increases the monetary base by issuing currency, increasing the amount banks have on reserve or by a process called [[wikipedia:Quantitative Easing|Quantitative Easing]].

In a fully decentralized monetary system, there is no central authority that regulates the monetary base. Instead, currency is created by the nodes of a peer-to-peer network. The Bitcoin generation algorithm defines, in advance, how currency will be created and at what rate. Any currency that is generated by a malicious user that does not follow the rules will be rejected by the network and thus is worthless.

==Currency with Finite Supply==
[[Image:Controlled supply-block reward halving.png|160px|thumb|right| Block reward halving]]
[[Image:Controlled supply-supply over block height.png|160px|thumb|right| Controlled supply]]
Bitcoins are created each time a user discovers a new [[block]].
The rate of block creation is adjusted every 2016 blocks to aim for a constant two week adjustment period (equivalent to 6 per hour.) The number of bitcoins generated per block is set to decrease geometrically, with a 50% reduction every 210,000 blocks, or approximately four years. The result is that the number of bitcoins in existence will not exceed slightly less than 21 million.<ref>[http://www.bitcointalk.org/index.php?topic=3366.msg47522#msg47522 21 million cap]</ref> Speculated justifications for the unintuitive value "21 million" are that it matches a 4-year reward halving schedule; or the ultimate total number of Satoshis that will be mined is close to the maximum capacity of a 64-bit floating point number. Satoshi has never really justified or explained many of these constants.

[[File:ControlledSupply.png]]

This decreasing-supply algorithm was chosen because it approximates the rate at which commodities like gold are mined. Users who use their computers to perform calculations to try and discover a block are thus called [[Mining|''Miners'']].

See also: https://bashco.github.io/

==Projected Bitcoins Short Term ==
This chart shows the number of bitcoins that will exist in the near future. The ''Year'' is a forecast and may be slightly off.
{| class="wikitable"
|-
! Date reached!!Block!!Reward Era!! BTC/block!! Year (estimate)!! Start BTC!! BTC Added!! End BTC!! BTC Increase|| End BTC % of Limit
|-
|2009-01-03||0||1||50.00||2009||0||2625000||2625000||infinite||12.500%
|-
|2010-04-22||52500||1||50.00||2010||2625000||2625000||5250000||100.00%||25.000%
|-
|2011-01-28||105000||1||50.00||2011*||5250000||2625000||7875000||50.00%||37.500%
|-
|2011-12-14||157500||1||50.00||2012||7875000||2625000||10500000||33.33%||50.000%
|-
|[[Halving day 2012|2012-11-28]]||210000||2||25.00||2013||10500000||1312500||11812500||12.50%||56.250%
|-
|2013-10-09||262500||2||25.00||2014||11812500||1312500||13125000||11.11%||62.500%
|-
|2014-08-11||315000||2||25.00||2015||13125000||1312500||14437500||10.00%||68.750%
|-
|2015-07-29||367500||2||25.00||2016||14437500||1312500||15750000||9.09%||75.000%
|-
|2016-07-09||420000||3||12.50||2016||15750000||656250||16406250||4.17%||78.125%
|-
|2017-06-23||472500||3||12.50||2018||16406250||656250||17062500||4.00%||81.250%
|-
|||525000||3||12.50||2019||17062500||656250||17718750||3.85%||84.375%
|-
|||577500||3||12.50||2020||17718750||656250||18375000||3.70%||87.500%
|-
|||630000||4||6.25||2021||18375000||328125||18703125||1.79%||89.063%
|-
|||682500||4||6.25||2022||18703125||328125||19031250||1.75%||90.625%
|-
|||735000||4||6.25||2023||19031250||328125||19359375||1.72%||92.188%
|-
|||787500||4||6.25||2024||19359375||328125||19687500||1.69%||93.750%
|}
''* In Block 124724, user midnightmagic mined a solo block to himself which underpaid the reward by a single Satoshi and simultaneously destroyed the block's fees. This is one of two only known reductions in the total mined supply of Bitcoin. Therefore, from block 124724 onwards, all total supply estimates must technically be reduced by 1 Satoshi.

==Projected Bitcoins Long Term ==
[[Image:Controlled supply-timeline estimation.png|160px|thumb|right| Supply timeline estimation]]
Because the number of bitcoins created each time a user discovers a new block - the block reward - is halved based on a fixed interval of blocks, and the time it takes on average to discover a block can vary based on [[mining]] power and the network [[difficulty]], the exact time when the block reward is halved can vary as well. Consequently, the time the last Bitcoin will be created will also vary, and is subject to speculation based on assumptions.

If the mining power had remained constant since the first Bitcoin was mined, the last Bitcoin would have been mined somewhere near October 8th, 2140. Due to the mining power having increased overall over time, as of block 367,500 - assuming mining power remained constant from that block forward - the last Bitcoin will be mined on May 7th, 2140.

As it is very difficult to predict how mining power will evolve into the future - i.e. whether technological progress will continue to make hardware faster or whether mining will hit a a technological wall; or whether or not faster methods of SHA2 calculation will be discovered - putting an exact date or even year on this event is difficult.

The total number of bitcoins, as mentioned earlier, has an asymptote at 21 million, due to a side-effect of the data structure of the blockchain - specifically the integer storage type of the [[Transaction#general_format_.28inside_a_block.29_of_each_output_of_a_transaction_-_Txout|transaction output]], this exact value would have been 20,999,999.9769 bitcoin. Should this technical limitation be adjusted by increasing the size of the field, the total number will still only approach a maximum of 21 million.

{| class="wikitable" style="text-align:right"
|-
! Block!!Reward Era!! BTC/block!! Start BTC!! BTC Added!! End BTC!! BTC Increase|| End BTC % of Limit
|-
| 0|| 1|| 50.00000000|| 0.00000000|| 10500000.00000000|| 10500000.00000000*|| infinite|| 50.00000006%
|-
| 210000|| 2|| 25.00000000|| 10500000.00000000|| 5250000.00000000|| 15750000.00000000|| 50.00000000%|| 75.00000008%
|-
| 420000|| 3|| 12.50000000|| 15750000.00000000|| 2625000.00000000|| 18375000.00000000|| 16.66666667%|| 87.50000010%
|-
| 630000|| 4|| 6.25000000|| 18375000.00000000|| 1312500.00000000|| 19687500.00000000|| 7.14285714%|| 93.75000010%
|-
| 840000|| 5|| 3.12500000|| 19687500.00000000|| 656250.00000000|| 20343750.00000000|| 3.33333333%|| 96.87500011%
|-
| 1050000|| 6|| 1.56250000|| 20343750.00000000|| 328125.00000000|| 20671875.00000000|| 1.61290323%|| 98.43750011%
|-
| 1260000|| 7|| 0.78125000|| 20671875.00000000|| 164062.50000000|| 20835937.50000000|| 0.79365079%|| 99.21875011%
|-
| 1470000|| 8|| 0.39062500|| 20835937.50000000|| 82031.25000000|| 20917968.75000000|| 0.39370079%|| 99.60937511%
|-
| 1680000|| 9|| 0.19531250|| 20917968.75000000|| 41015.62500000|| 20958984.37500000|| 0.19607843%|| 99.80468761%
|-
| 1890000|| 10|| 0.09765625|| 20958984.37500000|| 20507.81250000|| 20979492.18750000|| 0.09784736%|| 99.90234386%
|-
| 2100000|| 11|| 0.04882812|| 20979492.18750000|| 10253.90520000|| 20989746.09270000|| 0.04887585%|| 99.95117198%
|-
| 2310000|| 12|| 0.02441406|| 20989746.09270000|| 5126.95260000|| 20994873.04530000|| 0.02442599%|| 99.97558604%
|-
| 2520000|| 13|| 0.01220703|| 20994873.04530000|| 2563.47630000|| 20997436.52160000|| 0.01221001%|| 99.98779307%
|-
| 2730000|| 14|| 0.00610351|| 20997436.52160000|| 1281.73710000|| 20998718.25870000|| 0.00610426%|| 99.99389658%
|-
| 2940000|| 15|| 0.00305175|| 20998718.25870000|| 640.86750000|| 20999359.12620000|| 0.00305194%|| 99.99694833%
|-
| 3150000|| 16|| 0.00152587|| 20999359.12620000|| 320.43270000|| 20999679.55890000|| 0.00152592%|| 99.99847420%
|-
| 3360000|| 17|| 0.00076293|| 20999679.55890000|| 160.21530000|| 20999839.77420000|| 0.00076294%|| 99.99923713%
|-
| 3570000|| 18|| 0.00038146|| 20999839.77420000|| 80.10660000|| 20999919.88080000|| 0.00038146%|| 99.99961859%
|-
| 3780000|| 19|| 0.00019073|| 20999919.88080000|| 40.05330000|| 20999959.93410000|| 0.00019073%|| 99.99980932%
|-
| 3990000|| 20|| 0.00009536|| 20999959.93410000|| 20.02560000|| 20999979.95970000|| 0.00009536%|| 99.99990468%
|-
| 4200000|| 21|| 0.00004768|| 20999979.95970000|| 10.01280000|| 20999989.97250000|| 0.00004768%|| 99.99995236%
|-
| 4410000|| 22|| 0.00002384|| 20999989.97250000|| 5.00640000|| 20999994.97890000|| 0.00002384%|| 99.99997620%
|-
| 4620000|| 23|| 0.00001192|| 20999994.97890000|| 2.50320000|| 20999997.48210000|| 0.00001192%|| 99.99998812%
|-
| 4830000|| 24|| 0.00000596|| 20999997.48210000|| 1.25160000|| 20999998.73370000|| 0.00000596%|| 99.99999408%
|-
| 5040000|| 25|| 0.00000298|| 20999998.73370000|| 0.62580000|| 20999999.35950000|| 0.00000298%|| 99.99999706%
|-
| 5250000|| 26|| 0.00000149|| 20999999.35950000|| 0.31290000|| 20999999.67240000|| 0.00000149%|| 99.99999855%
|-
| 5460000|| 27|| 0.00000074|| 20999999.67240000|| 0.15540000|| 20999999.82780000|| 0.00000074%|| 99.99999929%
|-
| 5670000|| 28|| 0.00000037|| 20999999.82780000|| 0.07770000|| 20999999.90550000|| 0.00000037%|| 99.99999966%
|-
| 5880000|| 29|| 0.00000018|| 20999999.90550000|| 0.03780000|| 20999999.94330000|| 0.00000018%|| 99.99999984%
|-
| 6090000|| 30|| 0.00000009|| 20999999.94330000|| 0.01890000|| 20999999.96220000|| 0.00000009%|| 99.99999993%
|-
| 6300000|| 31|| 0.00000004|| 20999999.96220000|| 0.00840000|| 20999999.97060000|| 0.00000004%|| 99.99999997%
|-
| 6510000|| 32|| 0.00000002|| 20999999.97060000|| 0.00420000|| 20999999.97480000|| 0.00000002%|| 99.99999999%
|-
| 6720000|| 33|| 0.00000001|| 20999999.97480000|| 0.00210000|| 20999999.97690000|| 0.00000001%|| 100.00000000%
|-
| 6930000|| 34|| 0.00000000|| 20999999.97690000|| 0.00000000|| 20999999.97690000|| 0.00000000%|| 100.00000000%
|}
''Note: The number of bitcoins are presented in a floating point format. However, these values are based on the number of satoshi per block originally in integer format to prevent compounding error.''

''* In block 124724, user midnightmagic solo mined a block which caused one less Satoshi to be created than would otherwise have come into existence. Therefore, all calculations from this block onwards must now, to be accurate, include this underpay in total Bitcoins in existence. Then, in an act of sheer stupidity, a more recent miner who failed to implement RSK properly destroyed an entire block reward of 12.5 XBT in block 501726.''

==What happens when all the bitcoins are mined?==

The bitcoin inflation rate steadily trends downwards. At the time of writing, more than 3 out of every 4 bitcoins that will ever exist have already been mined, and the annual inflation rate is just 4%. The [[block]] reward given to miners is made up of newly-created bitcoins plus [[transaction fees]]. As inflation goes to zero miners will obtain an income only from transaction fees which will provide an incentive to keep mining to make transactions [[Irreversible Transactions|irreversible]].

Due to deep technical reasons, [[Transaction_fees#The_market_for_block_space|block space is a scarce commodity]], getting a transaction mined can be seen as purchasing a portion of it. By analogy, on average every 10 minutes a fixed amount of land is created and no more, people wanting to make transactions bid for parcels of this land. The sale of this land is what supports the miners even in a zero-inflation regime. The price of this land is set by demand for transactions (because the supply is fixed and known) and the mining [[difficulty]] readjusts around this to keep the average interval at 10 minutes.

==Spendable Supply==
The theoretical total number of bitcoins, slightly less than 21 million, should not be confused with the total spendable supply. The total spendable supply is always lower than the theoretical total supply, and is subject to accidental loss, willful destruction, and technical peculiarities.

One way to see a part of the destruction of coin is by collecting a sum of all unspent transaction outputs, using a [[API reference (JSON-RPC)|Bitcoin RPC]] command <code>gettxoutsetinfo</code>. The ''total_amount'' value returned is the sum of all outputs that the client deems technically spendable but not currently spent. Note however that this does not take into account outputs that are exceedingly unlikely to be spent as is the case in loss and destruction via constructed addresses, for example.
===Miner Underpay===

The algorithm which decides whether a block is valid only checks to verify whether the total amount of the reward '''exceeds''' the reward plus available fees. Therefore it is possible for a miner to deliberately choose to underpay himself by any value: not only can this destroy the fees involved, but also the reward itself, which can prevent the total possible bitcoins that can come into existence from reaching its theoretical maximum. This is a form of underpay which the reference implementation recognises as impossible to spend. Some of the other types below are not recognised as officially destroying Bitcoins; it is possible for example to spend the 1BitcoinEaterAddressDontSendf59kuE if a corresponding private key is used (although this would imply that Bitcoin has been broken.)

===Loss of bitcoin===
Bitcoins may be lost if the conditions required to spend them are no longer known. For example, if you made a transaction to an [[address]] that requires a private key in order to spend those bitcoins further, had written that private key down on a piece of paper, but that piece of paper was lost. In this case, that bitcoin may also be considered lost, as the odds of randomly finding a matching private key are such that it is generally considered impossible.

===Willful destruction of bitcoin===
Bitcoins may also be willfully 'destroyed' - for example by attaching conditions that make it impossible to spend them.

A common method is to send bitcoin to an address that was constructed and only made to pass validity checks, but for which no private key is actually known. An example of such an address is "1BitcoinEaterAddressDontSendf59kuE", where the last "f59kuE" is text to make the preceding constructed text pass validation. Finding a matching private key is, again, generally considered impossible. For an example of how difficult this would be, see [[Vanitygen#Use_of_vanitygen_to_try_to_attack_addresses|Vanitygen]].

Another common method is to send bitcoin in a transaction where the conditions for spending are not just unfathomably unlikely, but literally impossible to meet. For example, a transaction that is made [[Script#Provably_Unspendable.2FPrunable_Outputs|provably unspendable using OP_RETURN]], or uses script operations that requires the user to prove that 1+1 equals 3.

A lesser known method is to send bitcoin to an address based on private key that is outside the [[Private_key#Range_of_valid_ECDSA_private_keys|range of valid ECDSA private keys]]. For example, the address 16QaFeudRUt8NYy2yzjm3BMvG4xBbAsBFM has a known matching private key of value 0 (zero), which is outside the valid range.

===Technical peculiarities preventing spending of bitcoin===
There are also technical peculiarities that prevent the spending of some bitcoin.

The first {{btc}}50, included in the [[genesis block]], cannot be spent as its transaction is not in the global database.

In older versions of the bitcoin reference code, a miner could make their coinbase transaction (block reward) have the exact same ID as used in a previous block<ref>https://github.com/bitcoin/bitcoin/issues/612</ref>. This effectively caused the previous block reward to become unspendable. Two known such cases<ref>{{cite tx|e3bf3d07d4b0375638d5f1db5255fe07ba2c4cb067cd81b84ee974b6585fb468|used in blocks 91722 and 91880}}</ref><ref>{{cite tx|d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599|used in blocks 91812 and 91842</ref> are left as special cases in the code<ref>https://github.com/bitcoin/bitcoin/commit/ab91bf39b7c11e9c86bb2043c24f0f377f1cf514</ref> as part of [[BIP 0030]] changes that fixed this issue. These transactions were {{btc}}50 each.

==Money Supply==
While the number of bitcoins in existence will never exceed slightly less than 21 million, the [[wikipedia:money supply|money supply]] of bitcoins can exceed 21 million due to [[wikipedia:Fractional-reserve banking|Fractional-reserve banking]].

==Deflation==

Because the monetary base of bitcoins cannot be expanded, the currency would be subject to severe deflation if it becomes widely used.
Keynesian economists argue that [[Deflationary spiral|deflation]] is bad for an economy because it incentivises individuals and businesses to save money rather than invest in businesses and create jobs. The [[wikipedia:Austrian school|Austrian school]] of thought counters this criticism, claiming that as deflation occurs in all stages of production, entrepreneurs who invest benefit from it. As a result, profit ratios tend to stay the same and only their magnitudes change. In other words, in a deflationary environment, goods and services decrease in price, but at the same time the cost for the production of these goods and services tend to decrease proportionally, effectively not affecting profits. Price deflation encourages an increase in hoarding — hence savings — which in turn tends to lower interest rates and increase the incentive for entrepreneurs to invest in projects of longer term.

==See also==

* [http://www.econlib.org/library/Columns/y2006/Friedmantranscript.html Milton Friedman interview], where he proposed to replace the central bank with a computer, and to fix the money supply growth at 4% annually
* [[Deflationary spiral]]
* [http://blockchain.info/charts/total-bitcoins Chart of total bitcoins in circulation]
* [[Inflation]]
* [[Prohibited changes]]

==References==
<references />

[[Category:Economics]] [[Category:Technical]]

Block size limit controversy

2018-03-13T21:26:55Z

Midnightmagic: correcting stupid misinformation. wtf, Taras.

{{see also|Scalability FAQ}}
In 2010, a block size limit of 1 MB was introduced into Bitcoin by [[Satoshi Nakamoto]]. He added it hidden in two commits<ref>https://www.reddit.com/r/Bitcoin/comments/63859l/github_commit_where_satoshi_added_the_block_size/</ref><ref>[https://github.com/bitcoin/bitcoin/commit/a30b56eb "fix openssl linkage problems"], Sneaky soft-forking UASF commit for MAX_BLOCK_SIZE No. 1.</ref><ref>[https://github.com/bitcoin/bitcoin/commit/a790fa46f40 "don't count or spend payments until they have 1 confirmation"], Sneaky soft-forking UASF commit for MAX_BLOCK_SIZE No. 2.</ref> in secret. The original limit was equivalent to a soft-fork, since prior version of the software would accept the smaller blocks without issue—they were all forward-compatible with this change.

The limit was not changed again before Nakamoto disappeared and right now is part of bitcoin's consensus rules requiring a very invasive hard fork to change. As transaction volume increased with widespread Bitcoin adoption, increasing the limit became subject to heavy debate in 2015. 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.

According to a second-party (theymos,) Satoshi told people who discovered the new 1MB limit to "keep quiet" about it until the change was complete, in order to reduce controversy during the transition.<ref>[[https://www.reddit.com/r/Bitcoin/comments/3giend/citation_needed_satoshis_reason_for_blocksize/ctygzmi/ theymos explaining his experience with Satoshi keeping the 1MB change quiet]]</ref> The only evidence which asserts that the blocksize limit was an anti-DoS measure was a post from user Cryddit (Ray Dillinger) in 2015 which asserted that he was involved in the discussion itself and that the limit was there at launch..<ref>[[https://bitcointalk.org/index.php?topic=946236.msg10388435#msg10388435 Cryddit in 2015 stating he went over the first cut with Satoshi, and that the 1MB limit was there by the time Bitcoin launched.]]</ref> As per the secret commits, though, the limit was not added until July 14, 2010, which was a full 1.5 years ''after'' its launch.

== Arguments in favor of increasing the blocksize ==
* More transactions per second
* Off-chain solutions are not yet ready to take off the load from the main blockchain.

== Contentions ==
* Increased blocksize will leave space for extensions like Mastercoin, Counterparty, etc.
** Neutral: Bitcoin competitors will have lower fees
** Negative: Bitcoin full nodes are forced to use more resources that don't support Bitcoin
* Small blocks eventually will require higher fees for fast confirmations.
** Positive: It will no longer be cheap to spam transactions such as Satoshi Dice bets
** Positive: Fees will not be zero. This is eventually a necessity in order to incentivize miners and secure the mining ecosystem
** Negative: Bitcoin may look unattractive to new users with high fees
** Negative: High fees may stop or reverse global adoption, investment, development, support and centralization{{clarification needed}}
** Negative: Bitcoin users pay higher fees
* A low blocksize limit encourages higher transactions fees to incentivize miners ("let a fee market develop").
** 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>
*** 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.

== Arguments in opposition to increasing the blocksize ==
* A hard fork requires waiting for sufficient consensus.
* Risk of catastrophic consensus failure<ref>https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html</ref>{{clarification needed}}
* 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>
* Orphan rate amplification, more reorgs and double-spends due to slower propagation speeds.
* European/American pools at more of a disadvantage compared to the Chinese pools{{why}}
* "Congestion" concerns can be solved with mempool improvements including transaction eviction.
* 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)
* Fast block propagation is either not clearly viable, or (eg, IBLT) creates centralised controls.

=== Damage to decentralization ===
* Larger blocks make full nodes more expensive to operate.
* 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.
* Bitcoin is only useful if it is decentralized because centralization requires trust. Bitcoins value proposition is trustlessness.
* The larger the hash-rate a single miner controls, the more centralized Bitcoin becomes and the more trust using Bitcoin requires.
* 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.
* 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>.

==History==
On October 3, 2010, [[Jeff Garzik]] published a patch that immediately increases the block size to 7MB.<ref>{{cite btct|id=1347|title=(PATCH) increase block size limit|date=2010-10-03}}</ref> The patch had no users, but it was the earliest attempt at increasing the block size through a hardfork. Satoshi and theymos immediately said not to implement it, as it would make the user's node incompatible with the network.<ref name="dontuse">[[https://bitcointalk.org/index.php?topic=1347.msg15139#msg15139 "+1 theymos. Don't use this patch"]] Satoshi explains here that ''if'' a change is necessary, a hard fork ''could'' be implemented with a countdown.</ref> This is the oft-cited post which many people claim proves Satoshi intended for the blocksize to increase. English, however, does not work that way. Satoshi spoke conditionally, not intentionally.<ref name="dontuse" />
===BIP 100===
Change block size limit based on miner votes, but don't leave the range (1MB, 32MB) without a softfork or hardfork respectively.
===Bitcoin XT===
[[File:xt.png|thumb|128px|Bitcoin XT logo]]{{main|Bitcoin XT}}
Bitcoin XT was an alternative client that became notorious when it adopted BIP 101, which would direct an increase to 8 MB after both January 11, 2016 has passed and 75% of miners are in support, followed by doubling of the limit every two years with the size increasing linearly within those two year intervals.

XT failed to gain enough support to activate the hardfork, leading to Mike Hearn's resignation.
===BIP 102===
Increase to 2 MB on November 11, 2015.
===BIP 103===
Increase by 17.7% annually until 2063.
===Bitcoin Classic===
{{main|Bitcoin Classic}}
Adopt BIP 109 and hardfork to 2 MB in 2016. Dynamic max_block_size in 2017.
===Segregated Witness===
[[File:segwit.png|thumb|128px|SegWit logo]]{{main|Segregated Witness}}
Move signature data out of the 1 MB block and into a separate witness structure via a softfork, effectively raising the block capacity to 1.4 MB of transactions.

== Entities positions ==
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.
{| class="wikitable sortable"
! Entity
! Supports Larger Blocks
! Supports Hard Fork
|-
| [[Magnr]]
| {{Yes|Yes: "We believe an immediate 2mb blocksize increase is important and urgently required to enable Bitcoin to flourish and deliver more utilitarian use to more people all across the world."}}<ref>https://github.com/bitcoinclassic/website/issues/3#issuecomment-172678154</ref>
| {{Yes|Yes: "We support the Bitcoin Classic proposal<ref>https://bitcoinclassic.com</ref>."}} - Magnr<ref>https://twitter.com/magnr/status/689227046120222721</ref>
|-
| Bitcoinpaygate
| {{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>
|
|-
| Bitrated
| {{No}} "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>
|
|-
| [[GreenAddress]]
| {{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>
|
|-
| [[MPEx]]
| {{No}}<ref>http://log.bitcoin-assets.com//?date=07-01-2015#967332</ref>
|
|-
| [[Paymium]]
| {{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>
|
|-
| Ethereum 
| {{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>
|
|-
| [[F2Pool]]
| {{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>
|
|-
| [[Armory]]
| {{Yes}} "This *is* urgent and needs to be handled right now, and I believe Gavin
has the best approach to this." - CEO Alan Reiner<ref>http://sourceforge.net/p/bitcoin/mailman/message/34093337/</ref>
|
|-
| BitcoinReminder
| {{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>
|
|-
| BitHours
| {{Yes|Yes: "We support @gavinandresen and his proposal for 20mb blocks"}}<ref>https://twitter.com/bithours/status/605131647747358721</ref>
|
|-
| [[BitPay]]
| {{Yes}} "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>
| {{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>
|-
| Bittiraha.fi
| {{Yes|Yes: "We are supporting increasing #Bitcoin max block size to 20MB."}}<ref>https://twitter.com/Bittirahafi/status/596682373028311040</ref> "I'm strongly in favor of the block size cap increase to 20MB." - CEO Henry Brade<ref>https://twitter.com/Technom4ge/status/596334370803326978</ref>
| {{Yes}} "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>
|-
| [[Blockchain.info]]
|{{Yes}} "It is time to increase the block size. Agree with @gavinandresen" - CEO Peter Smith<ref>https://twitter.com/OneMorePeter/status/595676380320407553</ref> "Scaling #bitcoin is a big deal. Increase the block size." - Nic Cary<ref>https://twitter.com/niccary/status/595707211994763264</ref>
|
|-
| [[Blocktrail]]
|{{Yes}} "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> 
|
|-
| Breadwallet
| {{Yes}} "[...] in support of the Gavin's 20Mb block proposal." - CEO Aaron Voisine<ref>http://sourceforge.net/p/bitcoin/mailman/message/34096857/</ref>
|
|-
| [[BTC Guild]]

| {{Yes}} "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>
|
|-
| BX.in.th
| {{Yes|Yes: "<nowiki>http://BX.in.th</nowiki> will support the 20MB block size"}}<ref>https://twitter.com/BitcoinThai/status/605022509101023232</ref>
|
|-
| [[Coinbase (business)|CoinBase]]
| {{Yes|Yes: "Coinbase supports increasing the maximum block size"}}<ref>https://twitter.com/coinbase/status/595741967759335426</ref> "Why we should increase the block size" - CEO Brian Armstrong<ref>https://twitter.com/brian_armstrong/status/595453245884997634</ref>
| {{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>
|-
| [[Coinify]]
| {{Yes}} "We see Bitcoin XT as the best solution for ensuring the future scalability of the Bitcoin network." - CTO Hamed Sattari<ref>https://news.coinify.com/coinify-supports-bitcoin-xt-scalability-bitcoin-payments/</ref>
|
|-
| [[Adam Back]]
| {{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>
| {{No}} "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>
|
|-
| Kryptoradio
| {{Yes}} "#Kryptoradio dev @zouppen supports 20MB block size in #bitcoin." - Joel Lehtonen<ref>https://twitter.com/koodilehto/status/596675967667568641</ref>
|
|-
| [[OKCoin]]
| {{Yes|Yes: "OKCoin's tech team believes it's the right decision"}}<ref>https://twitter.com/okcoinbtc/status/598412795240009728</ref>
|
|-
| [[Third Key Solutions]]
| {{Yes}} "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>
|
|-
| [[Xapo]]
| {{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>
|
|}

==References==
<references/>
[[Category:2015 events]]

Controlled supply

2018-03-04T12:00:49Z

Midnightmagic: this 21 million thing is annoying me. plus, sigh, it turns out another miner threw away a whole 12.5 xbt

<blockquote>A fixed money supply, or a supply altered only in accord with objective and calculable criteria, is a necessary condition to a meaningful just price of money.<ref>[https://isidore.co/calibre/browse/book/5277 Interest and Usury] p. 220 by [https://www.jstor.org/stable/29769582 Fr. Bernard W. Dempsey, S.J.] (1903-1960); cf. John Horvat II [https://isidore.co/calibre/browse/book/5155 Return to Order] ch. 37 "The Backing of Money"</ref>
—[https://www.jstor.org/stable/29769582 Fr. Bernard W. Dempsey, S.J.] (1903-1960)</blockquote>

In a centralized economy, currency is issued by a central bank at a rate that is supposed to match the growth of the amount of goods that are exchanged so that these goods can be traded with stable prices. The
[[wikipedia:monetary base|monetary base]] is controlled by a central bank. In the United States, the [[wikipedia:Federal Reserve System|Fed]] increases the monetary base by issuing currency, increasing the amount banks have on reserve or by a process called [[wikipedia:Quantitative Easing|Quantitative Easing]].

In a fully decentralized monetary system, there is no central authority that regulates the monetary base. Instead, currency is created by the nodes of a peer-to-peer network. The Bitcoin generation algorithm defines, in advance, how currency will be created and at what rate. Any currency that is generated by a malicious user that does not follow the rules will be rejected by the network and thus is worthless.

==Currency with Finite Supply==
[[Image:Controlled supply-block reward halving.png|160px|thumb|right| Block reward halving]]
[[Image:Controlled supply-supply over block height.png|160px|thumb|right| Controlled supply]]
Bitcoins are created each time a user discovers a new [[block]].
The rate of block creation is adjusted every 2016 blocks to aim for a constant two week adjustment period (equivalent to 6 per hour.) The number of bitcoins generated per block is set to decrease geometrically, with a 50% reduction every 210,000 blocks, or approximately four years. The result is that the number of bitcoins in existence will not exceed slightly less than 21 million.<ref>[http://www.bitcointalk.org/index.php?topic=3366.msg47522#msg47522 21 million cap]</ref> Speculated justifications for the unintuitive value "21 million" are that it matches a 4-year reward halving schedule; or the ultimate total number of Satoshis that will be mined is close to the maximum capacity of a 64-bit floating point number. Satoshi has never really justified or explained many of these constants.

[[File:ControlledSupply.png]]

This decreasing-supply algorithm was chosen because it approximates the rate at which commodities like gold are mined. Users who use their computers to perform calculations to try and discover a block are thus called [[Mining|''Miners'']].

See also: https://bashco.github.io/

==Projected Bitcoins Short Term ==
This chart shows the number of bitcoins that will exist in the near future. The ''Year'' is a forecast and may be slightly off.
{| class="wikitable"
|-
! Date reached!!Block!!Reward Era!! BTC/block!! Year (estimate)!! Start BTC!! BTC Added!! End BTC!! BTC Increase|| End BTC % of Limit
|-
|2009-01-03||0||1||50.00||2009||0||2625000||2625000||infinite||12.500%
|-
|2010-04-22||52500||1||50.00||2010||2625000||2625000||5250000||100.00%||25.000%
|-
|2011-01-28||105000||1||50.00||2011*||5250000||2625000||7875000||50.00%||37.500%
|-
|2011-12-14||157500||1||50.00||2012||7875000||2625000||10500000||33.33%||50.000%
|-
|[[Halving day 2012|2012-11-28]]||210000||2||25.00||2013||10500000||1312500||11812500||12.50%||56.250%
|-
|2013-10-09||262500||2||25.00||2014||11812500||1312500||13125000||11.11%||62.500%
|-
|2014-08-11||315000||2||25.00||2015||13125000||1312500||14437500||10.00%||68.750%
|-
|2015-07-29||367500||2||25.00||2016||14437500||1312500||15750000||9.09%||75.000%
|-
|2016-07-09||420000||3||12.50||2016||15750000||656250||16406250||4.17%||78.125%
|-
|2017-06-23||472500||3||12.50||2018||16406250||656250||17062500||4.00%||81.250%
|-
|||525000||3||12.50||2019||17062500||656250||17718750||3.85%||84.375%
|-
|||577500||3||12.50||2020||17718750||656250||18375000||3.70%||87.500%
|-
|||630000||4||6.25||2021||18375000||328125||18703125||1.79%||89.063%
|-
|||682500||4||6.25||2022||18703125||328125||19031250||1.75%||90.625%
|-
|||735000||4||6.25||2023||19031250||328125||19359375||1.72%||92.188%
|-
|||787500||4||6.25||2024||19359375||328125||19687500||1.69%||93.750%
|}
''* In Block 124724, user midnightmagic mined a solo block to himself which underpaid the reward by a single Satoshi and simultaneously destroyed the block's fees. This the the only known reduction in the total mined supply of Bitcoin. Therefore, from block 124724 onwards, all total supply estimates must technically be reduced by 1 Satoshi.

==Projected Bitcoins Long Term ==
[[Image:Controlled supply-timeline estimation.png|160px|thumb|right| Supply timeline estimation]]
Because the number of bitcoins created each time a user discovers a new block - the block reward - is halved based on a fixed interval of blocks, and the time it takes on average to discover a block can vary based on [[mining]] power and the network [[difficulty]], the exact time when the block reward is halved can vary as well. Consequently, the time the last Bitcoin will be created will also vary, and is subject to speculation based on assumptions.

If the mining power had remained constant since the first Bitcoin was mined, the last Bitcoin would have been mined somewhere near October 8th, 2140. Due to the mining power having increased overall over time, as of block 367,500 - assuming mining power remained constant from that block forward - the last Bitcoin will be mined on May 7th, 2140.

As it is very difficult to predict how mining power will evolve into the future - i.e. whether technological progress will continue to make hardware faster or whether mining will hit a a technological wall; or whether or not faster methods of SHA2 calculation will be discovered - putting an exact date or even year on this event is difficult.

The total number of bitcoins, as mentioned earlier, has an asymptote at 21 million, due to a side-effect of the data structure of the blockchain - specifically the integer storage type of the [[Transaction#general_format_.28inside_a_block.29_of_each_output_of_a_transaction_-_Txout|transaction output]], this exact value would have been 20,999,999.9769 bitcoin. Should this technical limitation be adjusted by increasing the size of the field, the total number will still only approach a maximum of 21 million.

{| class="wikitable" style="text-align:right"
|-
! Block!!Reward Era!! BTC/block!! Start BTC!! BTC Added!! End BTC!! BTC Increase|| End BTC % of Limit
|-
| 0|| 1|| 50.00000000|| 0.00000000|| 10500000.00000000|| 10500000.00000000*|| infinite|| 50.00000006%
|-
| 210000|| 2|| 25.00000000|| 10500000.00000000|| 5250000.00000000|| 15750000.00000000|| 50.00000000%|| 75.00000008%
|-
| 420000|| 3|| 12.50000000|| 15750000.00000000|| 2625000.00000000|| 18375000.00000000|| 16.66666667%|| 87.50000010%
|-
| 630000|| 4|| 6.25000000|| 18375000.00000000|| 1312500.00000000|| 19687500.00000000|| 7.14285714%|| 93.75000010%
|-
| 840000|| 5|| 3.12500000|| 19687500.00000000|| 656250.00000000|| 20343750.00000000|| 3.33333333%|| 96.87500011%
|-
| 1050000|| 6|| 1.56250000|| 20343750.00000000|| 328125.00000000|| 20671875.00000000|| 1.61290323%|| 98.43750011%
|-
| 1260000|| 7|| 0.78125000|| 20671875.00000000|| 164062.50000000|| 20835937.50000000|| 0.79365079%|| 99.21875011%
|-
| 1470000|| 8|| 0.39062500|| 20835937.50000000|| 82031.25000000|| 20917968.75000000|| 0.39370079%|| 99.60937511%
|-
| 1680000|| 9|| 0.19531250|| 20917968.75000000|| 41015.62500000|| 20958984.37500000|| 0.19607843%|| 99.80468761%
|-
| 1890000|| 10|| 0.09765625|| 20958984.37500000|| 20507.81250000|| 20979492.18750000|| 0.09784736%|| 99.90234386%
|-
| 2100000|| 11|| 0.04882812|| 20979492.18750000|| 10253.90520000|| 20989746.09270000|| 0.04887585%|| 99.95117198%
|-
| 2310000|| 12|| 0.02441406|| 20989746.09270000|| 5126.95260000|| 20994873.04530000|| 0.02442599%|| 99.97558604%
|-
| 2520000|| 13|| 0.01220703|| 20994873.04530000|| 2563.47630000|| 20997436.52160000|| 0.01221001%|| 99.98779307%
|-
| 2730000|| 14|| 0.00610351|| 20997436.52160000|| 1281.73710000|| 20998718.25870000|| 0.00610426%|| 99.99389658%
|-
| 2940000|| 15|| 0.00305175|| 20998718.25870000|| 640.86750000|| 20999359.12620000|| 0.00305194%|| 99.99694833%
|-
| 3150000|| 16|| 0.00152587|| 20999359.12620000|| 320.43270000|| 20999679.55890000|| 0.00152592%|| 99.99847420%
|-
| 3360000|| 17|| 0.00076293|| 20999679.55890000|| 160.21530000|| 20999839.77420000|| 0.00076294%|| 99.99923713%
|-
| 3570000|| 18|| 0.00038146|| 20999839.77420000|| 80.10660000|| 20999919.88080000|| 0.00038146%|| 99.99961859%
|-
| 3780000|| 19|| 0.00019073|| 20999919.88080000|| 40.05330000|| 20999959.93410000|| 0.00019073%|| 99.99980932%
|-
| 3990000|| 20|| 0.00009536|| 20999959.93410000|| 20.02560000|| 20999979.95970000|| 0.00009536%|| 99.99990468%
|-
| 4200000|| 21|| 0.00004768|| 20999979.95970000|| 10.01280000|| 20999989.97250000|| 0.00004768%|| 99.99995236%
|-
| 4410000|| 22|| 0.00002384|| 20999989.97250000|| 5.00640000|| 20999994.97890000|| 0.00002384%|| 99.99997620%
|-
| 4620000|| 23|| 0.00001192|| 20999994.97890000|| 2.50320000|| 20999997.48210000|| 0.00001192%|| 99.99998812%
|-
| 4830000|| 24|| 0.00000596|| 20999997.48210000|| 1.25160000|| 20999998.73370000|| 0.00000596%|| 99.99999408%
|-
| 5040000|| 25|| 0.00000298|| 20999998.73370000|| 0.62580000|| 20999999.35950000|| 0.00000298%|| 99.99999706%
|-
| 5250000|| 26|| 0.00000149|| 20999999.35950000|| 0.31290000|| 20999999.67240000|| 0.00000149%|| 99.99999855%
|-
| 5460000|| 27|| 0.00000074|| 20999999.67240000|| 0.15540000|| 20999999.82780000|| 0.00000074%|| 99.99999929%
|-
| 5670000|| 28|| 0.00000037|| 20999999.82780000|| 0.07770000|| 20999999.90550000|| 0.00000037%|| 99.99999966%
|-
| 5880000|| 29|| 0.00000018|| 20999999.90550000|| 0.03780000|| 20999999.94330000|| 0.00000018%|| 99.99999984%
|-
| 6090000|| 30|| 0.00000009|| 20999999.94330000|| 0.01890000|| 20999999.96220000|| 0.00000009%|| 99.99999993%
|-
| 6300000|| 31|| 0.00000004|| 20999999.96220000|| 0.00840000|| 20999999.97060000|| 0.00000004%|| 99.99999997%
|-
| 6510000|| 32|| 0.00000002|| 20999999.97060000|| 0.00420000|| 20999999.97480000|| 0.00000002%|| 99.99999999%
|-
| 6720000|| 33|| 0.00000001|| 20999999.97480000|| 0.00210000|| 20999999.97690000|| 0.00000001%|| 100.00000000%
|-
| 6930000|| 34|| 0.00000000|| 20999999.97690000|| 0.00000000|| 20999999.97690000|| 0.00000000%|| 100.00000000%
|}
''Note: The number of bitcoins are presented in a floating point format. However, these values are based on the number of satoshi per block originally in integer format to prevent compounding error.''

''* In block 124724, user midnightmagic solo mined a block which caused one less Satoshi to be created than would otherwise have come into existence. Therefore, all calculations from this block onwards must now, to be accurate, include this underpay in total Bitcoins in existence. Then, in an act of sheer stupidity, a more recent miner who failed to implement RSK properly destroyed an entire block reward of 12.5 XBT in block 501726.''

==What happens when all the bitcoins are mined?==

The bitcoin inflation rate steadily trends downwards. At the time of writing, more than 3 out of every 4 bitcoins that will ever exist have already been mined, and the annual inflation rate is just 4%. The [[block]] reward given to miners is made up of newly-created bitcoins plus [[transaction fees]]. As inflation goes to zero miners will obtain an income only from transaction fees which will provide an incentive to keep mining to make transactions [[Irreversible Transactions|irreversible]].

Due to deep technical reasons, [[Transaction_fees#The_market_for_block_space|block space is a scarce commodity]], getting a transaction mined can be seen as purchasing a portion of it. By analogy, on average every 10 minutes a fixed amount of land is created and no more, people wanting to make transactions bid for parcels of this land. The sale of this land is what supports the miners even in a zero-inflation regime. The price of this land is set by demand for transactions (because the supply is fixed and known) and the mining [[difficulty]] readjusts around this to keep the average interval at 10 minutes.

==Spendable Supply==
The theoretical total number of bitcoins, slightly less than 21 million, should not be confused with the total spendable supply. The total spendable supply is always lower than the theoretical total supply, and is subject to accidental loss, willful destruction, and technical peculiarities.

One way to see a part of the destruction of coin is by collecting a sum of all unspent transaction outputs, using a [[API reference (JSON-RPC)|Bitcoin RPC]] command <code>gettxoutsetinfo</code>. The ''total_amount'' value returned is the sum of all outputs that the client deems technically spendable but not currently spent. Note however that this does not take into account outputs that are exceedingly unlikely to be spent as is the case in loss and destruction via constructed addresses, for example.
===Miner Underpay===

The algorithm which decides whether a block is valid only checks to verify whether the total amount of the reward '''exceeds''' the reward plus available fees. Therefore it is possible for a miner to deliberately choose to underpay himself by any value: not only can this destroy the fees involved, but also the reward itself, which can prevent the total possible bitcoins that can come into existence from reaching its theoretical maximum. This is a form of underpay which the reference implementation recognises as impossible to spend. Some of the other types below are not recognised as officially destroying Bitcoins; it is possible for example to spend the 1BitcoinEaterAddressDontSendf59kuE if a corresponding private key is used (although this would imply that Bitcoin has been broken.)

===Loss of bitcoin===
Bitcoins may be lost if the conditions required to spend them are no longer known. For example, if you made a transaction to an [[address]] that requires a private key in order to spend those bitcoins further, had written that private key down on a piece of paper, but that piece of paper was lost. In this case, that bitcoin may also be considered lost, as the odds of randomly finding a matching private key are such that it is generally considered impossible.

===Willful destruction of bitcoin===
Bitcoins may also be willfully 'destroyed' - for example by attaching conditions that make it impossible to spend them.

A common method is to send bitcoin to an address that was constructed and only made to pass validity checks, but for which no private key is actually known. An example of such an address is "1BitcoinEaterAddressDontSendf59kuE", where the last "f59kuE" is text to make the preceding constructed text pass validation. Finding a matching private key is, again, generally considered impossible. For an example of how difficult this would be, see [[Vanitygen#Use_of_vanitygen_to_try_to_attack_addresses|Vanitygen]].

Another common method is to send bitcoin in a transaction where the conditions for spending are not just unfathomably unlikely, but literally impossible to meet. For example, a transaction that is made [[Script#Provably_Unspendable.2FPrunable_Outputs|provably unspendable using OP_RETURN]], or uses script operations that requires the user to prove that 1+1 equals 3.

A lesser known method is to send bitcoin to an address based on private key that is outside the [[Private_key#Range_of_valid_ECDSA_private_keys|range of valid ECDSA private keys]]. For example, the address 16QaFeudRUt8NYy2yzjm3BMvG4xBbAsBFM has a known matching private key of value 0 (zero), which is outside the valid range.

===Technical peculiarities preventing spending of bitcoin===
There are also technical peculiarities that prevent the spending of some bitcoin.

The first {{btc}}50, included in the [[genesis block]], cannot be spent as its transaction is not in the global database.

In older versions of the bitcoin reference code, a miner could make their coinbase transaction (block reward) have the exact same ID as used in a previous block<ref>https://github.com/bitcoin/bitcoin/issues/612</ref>. This effectively caused the previous block reward to become unspendable. Two known such cases<ref>{{cite tx|e3bf3d07d4b0375638d5f1db5255fe07ba2c4cb067cd81b84ee974b6585fb468|used in blocks 91722 and 91880}}</ref><ref>{{cite tx|d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599|used in blocks 91812 and 91842</ref> are left as special cases in the code<ref>https://github.com/bitcoin/bitcoin/commit/ab91bf39b7c11e9c86bb2043c24f0f377f1cf514</ref> as part of [[BIP 0030]] changes that fixed this issue. These transactions were {{btc}}50 each.

==Money Supply==
While the number of bitcoins in existence will never exceed slightly less than 21 million, the [[wikipedia:money supply|money supply]] of bitcoins can exceed 21 million due to [[wikipedia:Fractional-reserve banking|Fractional-reserve banking]].

==Deflation==

Because the monetary base of bitcoins cannot be expanded, the currency would be subject to severe deflation if it becomes widely used.
Keynesian economists argue that [[Deflationary spiral|deflation]] is bad for an economy because it incentivises individuals and businesses to save money rather than invest in businesses and create jobs. The [[wikipedia:Austrian school|Austrian school]] of thought counters this criticism, claiming that as deflation occurs in all stages of production, entrepreneurs who invest benefit from it. As a result, profit ratios tend to stay the same and only their magnitudes change. In other words, in a deflationary environment, goods and services decrease in price, but at the same time the cost for the production of these goods and services tend to decrease proportionally, effectively not affecting profits. Price deflation encourages an increase in hoarding — hence savings — which in turn tends to lower interest rates and increase the incentive for entrepreneurs to invest in projects of longer term.

==See also==

* [http://www.econlib.org/library/Columns/y2006/Friedmantranscript.html Milton Friedman interview], where he proposed to replace the central bank with a computer, and to fix the money supply growth at 4% annually
* [[Deflationary spiral]]
* [http://blockchain.info/charts/total-bitcoins Chart of total bitcoins in circulation]
* [[Inflation]]
* [[Prohibited changes]]

==References==
<references />

[[Category:Economics]] [[Category:Technical]]

Talk:Comparison of cryptocurrencies

2018-01-10T23:26:41Z

Midnightmagic: /* Conspicuously missing links */

The order / grouping of these coins are still TBD.

==suggestion not to include market cap==
market cap changes too often, no point in adding that data to the wiki. Can just link to coinmarketcap or whatever.
[[User:Nanotube|Nanotube]] ([[User talk:Nanotube|talk]]) 22:44, 7 April 2014 (UTC)

[[User:Ripper234|Ripper234]] proposes a grouping of Major, Minor and New by an arbitrary market cap limit. This can be done once the market caps of the alts are known.
* Using market cap will make Tonal Bitcoin a "Major" despite de facto minor usage. Therefore, I suggest finding a different method of categorizing. --[[User:Luke-jr|Luke-jr]] ([[User talk:Luke-jr|talk]]) 05:06, 4 March 2013 (GMT)

**I have removed all market cap values. Nevertheless, I have ordered the list in two groups: Top 10 by market cap (according to http://coinmarketcap.com/), and the rest ordered alphabetical. I think that this is the best compromise. The "new" category was so old as to be laughable, as every day there are new coins being created. I don't think that it is in our best interest to have a definitive list of all crytpocurrencies, as there are now hundreds, and soon thousands. [[User:Lunokhod|Lunokhod]] ([[User talk:Lunokhod|talk]]) 09:49, 20 August 2014 (UTC)

*** I am going to re-remove the market-cap stuff soon, mostly because the values are meaningless and that there is no such thing as a currency market cap, and secondarily because the market cap value is so trivially manipulable. [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 18:42, 7 June 2017 (UTC)

==Removed Tonal bitcoin==

I have removed [[Tonal Bitcoin]] (TBC) from the list because it is not an alternative currency, it has no market cap, it can not be traded, and it is not accepted for payments anywhere. As far as I can tell, tonal bitcoin is just a way of representing bitcoin amounts using the tonal number system. If this is true, it is part of bitcoin, and is thus not a separate currency. This should be discussed elsewhere in this wiki, not here [[User:Lunokhod|Lunokhod]] ([[User talk:Lunokhod|talk]]) 09:49, 20 August 2014 (UTC)

* It is an alternative currency, and one of the few legit ones. It shares a market cap with BTC, and can be traded just like any other currency. Sharing a blockchain, or at least values, with BTC is the ideal for altcoins, and necessary to protect against scammer abuses. --[[User:Luke-jr|Luke-jr]] ([[User talk:Luke-jr|talk]]) 11:49, 20 August 2014 (UTC)

**Could you please provide some supporting evidence? Such as a project web page, etc? I can't find any information to back up your claims. [[User:Lunokhod|Lunokhod]] ([[User talk:Lunokhod|talk]]) 20:25, 20 August 2014 (UTC)

***I linked the [[Tonal Bitcoin]] article in the heading. You can also read a more user-friendly summary on the [https://bitcointalk.org/index.php?topic=218388.0 BitcoinTalk forum thread] for it. --[[User:Luke-jr|Luke-jr]] ([[User talk:Luke-jr|talk]]) 13:53, 21 August 2014 (UTC)

==Scamcoin removals==

There are quite a number of scamcoins listed on there. Ripple, for example, is pretty much a pure scamcoin. Dash is a scamcoin. Bytecoin is 100% a scamcoin which underwent silent, broken inflation thanks to a cryptonote flaw. It's important that a Bitcoin Wiki not promote coins that have a highly scam-filled history. [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 18:49, 7 June 2017 (UTC)
** WARNING: User davidhedlund, we can either discuss the contents of this page in here, or I'm going to have to remove your edit rights. Please stop adding back in scamcoins on the comparison page. [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 23:16, 21 September 2017 (UTC)

:Midnightmagic: I'm sorry, its not my intention to promote scamcoins. Can you please 1) Add comments in the article in the website fields for Bitcoin Cash and DASH why bitcoincash.org and dash.org respectively should not be visible? 2) motivate why you think these cryptocurrencies are scamcoins?:
* Dash: "Dash is a massive premine with masternodes that are likely dominated by said premine. The preminers thanks to Dash's built-in centralizing reward system are essentially guaranteed to maintain with less hashrate, their dominance due to the 45% forced reward system.
:: Yep. Pretty much. [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 01:50, 19 December 2017 (UTC)
* NEM: "NEM is a PoS coin." - https://en.wikipedia.org/wiki/Proof-of-stake#Criticism
:: PoS has nothing-at-stake. No point in listing scamcoins with PoS. [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 01:50, 19 December 2017 (UTC)
* Ripple: ?
::Ripple is a massive scamcoin and has no basis whatsoever in reality. It jumped on Ryan Fugger's coattails, and ran off with what would eventually end up being a SEC-fined scamcoin which destroyed even its own P2P stand-in token mechanism. Its market "cap" is a joke because the centralized tokens can simply be issued by the centralized creator of the tokens. [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 01:50, 19 December 2017 (UTC)
--[[User:Davidhedlund|Davidhedlund]] ([[User talk:Davidhedlund|talk]]) 22:44, 2 October 2017 (UTC)

:: Hello. Thanks for posting in here. Dash is a massive premine with masternodes that are likely dominated by said premine. The preminers thanks to Dash's built-in centralizing reward system are essentially guaranteed to maintain with less hashrate, their dominance due to the 45% forced reward system. Ripple is a centralized non-currency scam which has been fined multiple times, and involved in significant lawsuits with the end effect being its current form is essentially purely a cash grab. NEM is a PoS coin. XEM is just the ticker for NEM isn't it? [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 11:00, 4 October 2017 (UTC)

:::Thank you for your response. Yes XEM is the ticker so I removed it from my list in this Talk page. I have a few questions left:
* Can you please have a look at https://en.bitcoin.it/w/index.php?title=Comparison_of_cryptocurrencies&diff=64059&oldid=63963 the websites must be commented because someone else will add them otherwise.
::::I'm fine with removing them over time. [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 01:50, 19 December 2017 (UTC)
* Regarding BCH, please update the comment that I added in this revision: https://en.bitcoin.it/w/index.php?title=Comparison_of_cryptocurrencies&oldid=64067
* Please motivate why Ripple should be banned.
:::: Ripple is a scamcoin. There's no point in driving traffic to a scamcoin. But it's not banned. It's just not a legitimate comparison to make with Bitcoin. [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 01:50, 19 December 2017 (UTC)
* Remove Dash from the article or motivate why it should stay there.
:::: I agree. Probably Dash should be removed. Probably all the scamcoins should be removed. Literally the only reason they're still there is you keep editing this page. :-) [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 01:50, 19 December 2017 (UTC)
* Is it ok if I add a ==Blacklisted== section in the article and use the quotes that I updated to my list above?
:::: Probably not. Otherwise the list would stretch into the thousands. It'd be useless. [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 01:50, 19 December 2017 (UTC)

==Bcash Symbol==

The Bitcoin Cash developers are extremely hostile to Bitcoin, and consist of e.g. deadalnix who is an unapologetic copyright thief. Their attempt to conflate "Bitcoin Cash" with "Bitcoin" includes a mistaken co-opting of another scamcoin's symbol, "BCC" which is already being traded on some exchanges as BCC. The way to disambiguate it from the prior scamcoin is to use BCH, which is the symbol both exchanges, and ticker sites use. They can call it what they want, but given the level of hostility, it really doesn't make sense to contribute to user confusion here. (Note the huge spike in the *scamcoin* BCC around August 1 for an example of this deliberate obfuscation.) [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 00:55, 22 September 2017 (UTC)

== Anonymity ==

[[User:Midnightmagic|Midnightmagic]]: Can you motivate why you added [https://en.bitcoin.it/w/index.php?title=Comparison_of_cryptocurrencies&diff=63959&oldid=63941 changed] these cryptocurrencies from "High" to "Medium" anonymity (they are our best bet in terms of anonymity):
* Monero: ? (recently introduced "Ring Confidential Transactions" so it is regarded as anonymous by many)
* Zcash]: ?
:: They are medium anonymity because zcash's anonymity set is very small; Monero's is larger but not impenetrable; besides, listening in on the network provides a great deal of information that a pure analysis of the blockchain itself does not. [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 01:50, 19 December 2017 (UTC)
--[[User:Davidhedlund|Davidhedlund]] ([[User talk:Davidhedlund|talk]]) 19:07, 4 October 2017 (UTC)

== Conspicuously missing links ==

[[User:Oflameo|Oflameo]]: Conspicuously missing links look terrible from a wiki perspective. It would look better to add the links back for https://www.bitcoincash.org and https://www.dash.org/ and say what you need to say about them on the internal page. "It is a scamcoin" is not appropriate criteria when Big Media is saying just that about Bitcoin. That is why a whole article is necessary to prove the claim.
:: Big Media is not an authority on cryptocurrencies. That comparison is false. This is the Bitcoin wiki. We can elevate ourselves to a better standard than that. Conspicuously missing links are fine. [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 01:50, 19 December 2017 (UTC)

::: [[User:Oflameo|Oflameo]]: You aren't making an effort to be any better then Big Media [[User talk:Midnightmagic|talk]]. What you are doing is going '''Scamcoin! REEE! CensorZap!'''. Please define an an explicit criteria for a scamcoin so we can properly flag samcoins. What you said on these talk pages so far aren't very convincing IMO. Your actions are evidently anti-productive. [[User:Oflameo|Oflameo]] ([[User talk:Oflameo|talk]]) 22:25, 10 January 2018 (UTC)

:::: Use the four-tildes at the end of your note to sign it. A scamcoin is one which has no sound technological advances nor engineering behind it; is a premined coin with a history based in illegal behaviour or law-evading behaviour; is one which incompetent people have built it or are enriching themselves at the expense of innocent victims to whom they are lying to try to get them to dump money into it; or one which makes technical claims about a coin which are not founded in reality; or one which pumps itself endlessly in seminars. Fraud is usually central to a scamcoin. This is the Bitcoin wiki. This is not put-your-favourite-scamcoin-in-here-for-SEO-purposes-wiki. Please stop marking up the Bitcoin wiki with links to coins which are based in scams or I'll simply delete this page to avoid this argument altogether. To be honest, I'm about 45% of the way to deleting this page in its entirety to begin with, since it seems to be attracting angry argumentative people who have bad attitudes and make stupid comparisons between me and whoever they have a beef with. [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 23:26, 10 January 2018 (UTC)

User talk:Midnightmagic

2018-01-10T23:17:32Z

Midnightmagic: /* Trade page */

Hello, thank you for your message on my talk page. Upon reflection I wholeheartedly agree, I acted improperly, and let groupthink / personal attitudes get the better of me. This won't happen again. Best, [[User:Gladoscc|Gladoscc]] ([[User talk:Gladoscc|talk]]) 04:24, 1 March 2015 (UTC)

I replied [[User talk:Bitcoinomy|here]], thanks. [[User:Bitcoinomy|Bitcoinomy]] ([[User talk:Bitcoinomy|talk]]) 12:45, 19 August 2015 (UTC)

== Comparison of cryptocurrencies ==

Thank you for taking your time. I added more questions in
* https://en.bitcoin.it/wiki/Talk:Comparison_of_cryptocurrencies#Scamcoin_removals again
* https://en.bitcoin.it/wiki/Talk:Comparison_of_cryptocurrencies#Anonymity
--[[User:Davidhedlund|Davidhedlund]] ([[User talk:Davidhedlund|talk]]) 19:09, 4 October 2017 (UTC)

== Bitcoin Cash ==

I added your text to https://en.bitcoin.it/wiki/Bitcoin_Cash

== Blockonomics page removed ==

Hi,

Can you please explain the reasons for this when other page like https://en.bitcoin.it/wiki/CoinGate, https://en.bitcoin.it/wiki/BitPay and https://en.bitcoin.it/wiki/Gourl still exist

: Yeah, exactly. BitPay is going to stay but be modified to describe their current position on S2X. That is an important topic for Bitcoin users. I haven't gotten to deleting everything yet. I'm only one person, and I don't like doing it all at once. Too many people complaining. Also, sign your name next time. [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 04:11, 11 October 2017 (UTC)

== Trade page ==

Hello,

It seems you have recently deleted the page "Trade".

I believe that was a horribly misguided decision. While the page is hopelessly outdated and of no practical use, its importance as a historical reference is tremendous, especially its edit history. The history seems to be inaccessible now that it has been deleted.

I implore you to restore the page and simply edit it to include a deprecation notice instead of the original list.

Thanks. [[User:Holy-Fire|Holy-Fire]] ([[User talk:Holy-Fire|talk]]) 11:45, 9 January 2018 (UTC)

* No, I'm not going to do that. The page was a direct link to scams; as an accessible link to e.g. search engines, we were also unwillingly acting as an SEO vector. For scams. Not interested in that. If you have a better way of curating a business linkfarm, I strongly recommend you build one. If it's good, I will personally guarantee that I will build a page here and direct people at your well-curated business directory. [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 23:17, 10 January 2018 (UTC)