Scalability - Revision history

Gmaxwell: This text was written before opencoin unethically bought the name "ripple" and stuck it on an unrelated centeralized system. Lightning is the moral successor to the ripple idea applied to Bitcoin..

2020-12-29T03:50:41Z

This text was written before opencoin unethically bought the name "ripple" and stuck it on an unrelated centeralized system. Lightning is the moral successor to the ripple idea applied to Bitcoin..

← Older revision		Revision as of 03:50, 29 December 2020
Line 17:		Line 17:
	Bitcoin users sometimes gloss over this fact too quickly because people are too quick to call it a flaw but this is unfair. No one system is ideal for all usage and Bitcoin has a broader spectrum of qualities than most monetary instruments. If the bitcoin community isn't willing to point out some things would better be done by other systems then it becomes easy to make strawman arguments: If we admit that bitcoin could be used as a floor wax and desert topping, someone will always point out that it's not the best floorwax or best desert topping.		Bitcoin users sometimes gloss over this fact too quickly because people are too quick to call it a flaw but this is unfair. No one system is ideal for all usage and Bitcoin has a broader spectrum of qualities than most monetary instruments. If the bitcoin community isn't willing to point out some things would better be done by other systems then it becomes easy to make strawman arguments: If we admit that bitcoin could be used as a floor wax and desert topping, someone will always point out that it's not the best floorwax or best desert topping.

	It's trivial to build payment processing and credit systems _on top_ of bitcoin, both classic ones (like Visa itself!) as well as ~~self-proclaimed~~ "decentralized" ones like ~~Ripple~~. These systems could handle higher transaction volumes with lower costs, and settle frequently to the bitcoin that backs them. These could use other techniques with different tradeoffs than bitcoin, but still be backed and denominated by bitcoin so still enjoy its lack of central control. We see the beginnings of this today with bitcoin exchange and wallet services allowing instant payments between members.		It's trivial to build payment processing and credit systems _on top_ of bitcoin, both classic ones (like Visa itself!) as well as "decentralized" ones like Lightning. These systems could handle higher transaction volumes with lower costs, and settle frequently to the bitcoin that backs them. These could use other techniques with different tradeoffs than bitcoin, but still be backed and denominated by bitcoin so still enjoy its lack of central control. We see the beginnings of this today with bitcoin exchange and wallet services allowing instant payments between members.

	These services would gain the benefit of the stable inflation resistant bitcoin currency, users would gain the benefits of instant transactions, credit, and anti-fraud, bitcoin overall would enjoy improved scaling from offloaded transaction volume without compromising its decentralized nature. In a world where bitcoin was widely used payment processing systems would probably have lower prices because they would need to compete with raw-bitcoin transactions, they also could be afford lower price because frequent bitcoin settling (and zero trust bitcoin escrow transactions) would reduce their risk. This is doubly true because bitcoin could conceivably scale to replace them entirely, even if that wouldn't be the best idea due to the resulting reduction in decentralization.		These services would gain the benefit of the stable inflation resistant bitcoin currency, users would gain the benefits of instant transactions, credit, and anti-fraud, bitcoin overall would enjoy improved scaling from offloaded transaction volume without compromising its decentralized nature. In a world where bitcoin was widely used payment processing systems would probably have lower prices because they would need to compete with raw-bitcoin transactions, they also could be afford lower price because frequent bitcoin settling (and zero trust bitcoin escrow transactions) would reduce their risk. This is doubly true because bitcoin could conceivably scale to replace them entirely, even if that wouldn't be the best idea due to the resulting reduction in decentralization.

Furunodo at 13:12, 27 June 2020

2020-06-27T13:12:18Z

← Older revision		Revision as of 13:12, 27 June 2020
Line 1:		Line 1:
	[Note: This page is seriously outdated and largely unmaintained; due to past incidents of edit-warring it has not been subject to much peer review.]		'''''Note: This page is seriously outdated and largely unmaintained; due to past incidents of edit-warring it has not been subject to much peer review.'''''

	A Bitcoin full node could be modified to scale to much higher transaction rates than are seen today, assuming that said node is running on a high end servers rather than a desktop. Bitcoin was designed to support lightweight clients that only process small parts of the block chain (see ''simplified payment verification'' below for more details on this).		A Bitcoin [[full node]] could be modified to scale to much higher transaction rates than are seen today, assuming that said node is running on a high end servers rather than a desktop. Bitcoin was designed to support lightweight clients that only process small parts of the block chain (see ''simplified payment verification'' below for more details on this).

	''Please note that this page exists to give calculations about the scalability of a Bitcoin full node and transactions on the block chain without regards to network security and decentralization. It is not intended to discuss the scalability of alternative protocols or try and summarise philosophical debates. Create alternative pages if you want to do that.''		''Please note that this page exists to give calculations about the scalability of a Bitcoin full node and transactions on the block chain without regards to network security and decentralization. It is not intended to discuss the scalability of alternative protocols or try and summarise philosophical debates. Create alternative pages if you want to do that.''

Furunodo at 13:05, 27 June 2020

2020-06-27T13:05:27Z

← Older revision		Revision as of 13:05, 27 June 2020
Line 61:		Line 61:
	Only a small number of archival nodes need to store the full chain going back to the genesis block. These nodes can be used to bootstrap new fully validating nodes from scratch but are otherwise unnecessary.		Only a small number of archival nodes need to store the full chain going back to the genesis block. These nodes can be used to bootstrap new fully validating nodes from scratch but are otherwise unnecessary.

	The primary limiting factor in Bitcoin's performance is disk seeks once the unspent transaction output set stops fitting in memory. Once hard disks are phased out in favour of SSDs, it is quite possible that access to the UTXO set never becomes a serious bottleneck.		The primary limiting factor in Bitcoin's performance is disk seeks once the unspent transaction output set stops fitting in memory. Once hard disks are phased out in favour of SSDs, it is quite possible that access to the [[UTXO]] set never becomes a serious bottleneck.

	==Optimizations==		==Optimizations==

Furunodo: clarified ripple

2020-06-06T13:51:46Z

clarified ripple

← Older revision		Revision as of 13:51, 6 June 2020
Line 17:		Line 17:
	Bitcoin users sometimes gloss over this fact too quickly because people are too quick to call it a flaw but this is unfair. No one system is ideal for all usage and Bitcoin has a broader spectrum of qualities than most monetary instruments. If the bitcoin community isn't willing to point out some things would better be done by other systems then it becomes easy to make strawman arguments: If we admit that bitcoin could be used as a floor wax and desert topping, someone will always point out that it's not the best floorwax or best desert topping.		Bitcoin users sometimes gloss over this fact too quickly because people are too quick to call it a flaw but this is unfair. No one system is ideal for all usage and Bitcoin has a broader spectrum of qualities than most monetary instruments. If the bitcoin community isn't willing to point out some things would better be done by other systems then it becomes easy to make strawman arguments: If we admit that bitcoin could be used as a floor wax and desert topping, someone will always point out that it's not the best floorwax or best desert topping.

	It's trivial to build payment processing and credit systems _on top_ of bitcoin, both classic ones (like Visa itself!) as well as decentralized ones like ~~[http://ripple-project.org/~~ Ripple]. These systems could handle higher transaction volumes with lower costs, and settle frequently to the bitcoin that backs them. These could use other techniques with different tradeoffs than bitcoin, but still be backed and denominated by bitcoin so still enjoy its lack of central control. We see the beginnings of this today with bitcoin exchange and wallet services allowing instant payments between members.		It's trivial to build payment processing and credit systems _on top_ of bitcoin, both classic ones (like Visa itself!) as well as self-proclaimed "decentralized" ones like Ripple. These systems could handle higher transaction volumes with lower costs, and settle frequently to the bitcoin that backs them. These could use other techniques with different tradeoffs than bitcoin, but still be backed and denominated by bitcoin so still enjoy its lack of central control. We see the beginnings of this today with bitcoin exchange and wallet services allowing instant payments between members.

	These services would gain the benefit of the stable inflation resistant bitcoin currency, users would gain the benefits of instant transactions, credit, and anti-fraud, bitcoin overall would enjoy improved scaling from offloaded transaction volume without compromising its decentralized nature. In a world where bitcoin was widely used payment processing systems would probably have lower prices because they would need to compete with raw-bitcoin transactions, they also could be afford lower price because frequent bitcoin settling (and zero trust bitcoin escrow transactions) would reduce their risk. This is doubly true because bitcoin could conceivably scale to replace them entirely, even if that wouldn't be the best idea due to the resulting reduction in decentralization.		These services would gain the benefit of the stable inflation resistant bitcoin currency, users would gain the benefits of instant transactions, credit, and anti-fraud, bitcoin overall would enjoy improved scaling from offloaded transaction volume without compromising its decentralized nature. In a world where bitcoin was widely used payment processing systems would probably have lower prices because they would need to compete with raw-bitcoin transactions, they also could be afford lower price because frequent bitcoin settling (and zero trust bitcoin escrow transactions) would reduce their risk. This is doubly true because bitcoin could conceivably scale to replace them entirely, even if that wouldn't be the best idea due to the resulting reduction in decentralization.

Belcher: Add to category scalability

2019-02-15T20:25:59Z

Add to category scalability

← Older revision		Revision as of 20:25, 15 February 2019
Line 96:		Line 96:

	[[Category:Technical]]		[[Category:Technical]]
			[[Category:Scalability]]

Belcher: /* Related work */ spelling

2017-05-12T17:20:47Z

Related work: spelling

← Older revision		Revision as of 17:20, 12 May 2017
Line 93:		Line 93:
	* [https://bitcointalk.org/index.php?topic=88208.0 Ultimate blockchain compression] - the idea that the blockchain can be compressed to achieve "trust-free lite nodes"		* [https://bitcointalk.org/index.php?topic=88208.0 Ultimate blockchain compression] - the idea that the blockchain can be compressed to achieve "trust-free lite nodes"
	* [http://cryptonite.info/files/mbc-scheme-rev2.pdf The Finite Blockchain] paper that describes splitting the blockchain into three data structures, each better suited for its purpose. The three data structures are a finite blockchain (keep N blocks into the past), an "account tree" which keeps account balance for every address with a non-zero balance, and a "proof chain" which is an (ever growing) slimmed down version of the blockchain.		* [http://cryptonite.info/files/mbc-scheme-rev2.pdf The Finite Blockchain] paper that describes splitting the blockchain into three data structures, each better suited for its purpose. The three data structures are a finite blockchain (keep N blocks into the past), an "account tree" which keeps account balance for every address with a non-zero balance, and a "proof chain" which is an (ever growing) slimmed down version of the blockchain.
	* [https://lightning.network/ Lightning Network], an alternative protocol for transaction clearance in which ~~node~~ set up micropayment channels between each other and settle up on the block chain occasionally. Ordinary users interact primarily or only with payment channels and only use the blockchain for large transfers and cold storage.		* [https://lightning.network/ Lightning Network], an alternative protocol for transaction clearance in which nodes set up micropayment channels between each other and settle up on the block chain occasionally. Ordinary users interact primarily or only with payment channels and only use the blockchain for large transfers and cold storage.

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

Belcher: /* Related work */ removed phrase "payment hubs"

2017-05-12T17:18:31Z

Related work: removed phrase "payment hubs"

← Older revision		Revision as of 17:18, 12 May 2017
Line 93:		Line 93:
	* [https://bitcointalk.org/index.php?topic=88208.0 Ultimate blockchain compression] - the idea that the blockchain can be compressed to achieve "trust-free lite nodes"		* [https://bitcointalk.org/index.php?topic=88208.0 Ultimate blockchain compression] - the idea that the blockchain can be compressed to achieve "trust-free lite nodes"
	* [http://cryptonite.info/files/mbc-scheme-rev2.pdf The Finite Blockchain] paper that describes splitting the blockchain into three data structures, each better suited for its purpose. The three data structures are a finite blockchain (keep N blocks into the past), an "account tree" which keeps account balance for every address with a non-zero balance, and a "proof chain" which is an (ever growing) slimmed down version of the blockchain.		* [http://cryptonite.info/files/mbc-scheme-rev2.pdf The Finite Blockchain] paper that describes splitting the blockchain into three data structures, each better suited for its purpose. The three data structures are a finite blockchain (keep N blocks into the past), an "account tree" which keeps account balance for every address with a non-zero balance, and a "proof chain" which is an (ever growing) slimmed down version of the blockchain.
	* [https://lightning.network/ Lightning Network], an alternative protocol for transaction clearance in which ~~payment hubs~~ set up micropayment channels between each other and settle up on the block chain occasionally. Ordinary users interact primarily or only with ~~hubs~~.		* [https://lightning.network/ Lightning Network], an alternative protocol for transaction clearance in which node set up micropayment channels between each other and settle up on the block chain occasionally. Ordinary users interact primarily or only with payment channels and only use the blockchain for large transfers and cold storage.

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

Midnightmagic: restoring original page edit. Reverting Mike's removal of useful mainpage material.

2016-12-04T19:47:02Z

restoring original page edit. Reverting Mike's removal of useful mainpage material.

← Older revision		Revision as of 19:47, 4 December 2016
Line 4:		Line 4:

	''Please note that this page exists to give calculations about the scalability of a Bitcoin full node and transactions on the block chain without regards to network security and decentralization. It is not intended to discuss the scalability of alternative protocols or try and summarise philosophical debates. Create alternative pages if you want to do that.''		''Please note that this page exists to give calculations about the scalability of a Bitcoin full node and transactions on the block chain without regards to network security and decentralization. It is not intended to discuss the scalability of alternative protocols or try and summarise philosophical debates. Create alternative pages if you want to do that.''

			==Note to Readers==

			When techies hear about how bitcoin works they frequently stop at the word "flooding" and say "Oh-my-god! that can't scale!". The purpose of this article is to take an extreme example, the peak transaction rate of Visa, and show that bitcoin ''could'' technically reach that kind of rate without any kind of questionable reasoning, changes in the core design, or non-existent overlays. As such, it's merely an extreme example— not a plan for how bitcoin will grow to address wider needs (as a decentralized system it is the bitcoin using public who will decide how bitcoin grows)— it's just an argument that shows that bitcoin's core design can scale much better than an intelligent person might guess at first.

			Dan rightly criticizes the analysis presented here— pointing out that operating at this scale would significantly reduce the decentralized nature of bitcoin: If you have to have many terabytes of disk space to run a "full validating" node then fewer people will do it, and everyone who doesn't will have to trust the ones who do to be honest. Dan appears (from his slides) to have gone too far with that argument: he seems to suggest that this means bitcoins will be controlled by the kind of central banks that are common today. His analysis fails for two reasons (and the second is the fault of this page being a bit misleading):

			First, even at the astronomic scale presented here the required capacity is well within the realm of (wealthy) private individuals, and certainly would be at some future time when that kind of capacity was required. A system which puts private individuals, or at least small groups of private parties, on equal footing with central banks could hardly be called a centralized one, though it would be less decentralized than the bitcoin we have today. The system could also not get to this kind of scale without bitcoin users agreeing collectively to increase the maximum block size, so it's not an outcome that can happen without the consent of bitcoin users.

			Second, and most importantly, the assumed scaling described here deals with Bitcoin replacing visa. This is a poor comparison because bitcoin alone is not a perfect replacement for visa for reasons completely unrelated to scaling: Bitcoin does not offer instant transactions, credit, or various anti-fraud mechanisms (which some people want, even if not everyone does), for example. Bitcoin is a more complete replacement for checks, wire transfers, money orders, gold coins, CDs, savings accounts, etc. and if widely adopted probably replace the uses of credit cards which would be better served by these other things if they worked better online.

			Bitcoin users sometimes gloss over this fact too quickly because people are too quick to call it a flaw but this is unfair. No one system is ideal for all usage and Bitcoin has a broader spectrum of qualities than most monetary instruments. If the bitcoin community isn't willing to point out some things would better be done by other systems then it becomes easy to make strawman arguments: If we admit that bitcoin could be used as a floor wax and desert topping, someone will always point out that it's not the best floorwax or best desert topping.

			It's trivial to build payment processing and credit systems _on top_ of bitcoin, both classic ones (like Visa itself!) as well as decentralized ones like [http://ripple-project.org/ Ripple]. These systems could handle higher transaction volumes with lower costs, and settle frequently to the bitcoin that backs them. These could use other techniques with different tradeoffs than bitcoin, but still be backed and denominated by bitcoin so still enjoy its lack of central control. We see the beginnings of this today with bitcoin exchange and wallet services allowing instant payments between members.

			These services would gain the benefit of the stable inflation resistant bitcoin currency, users would gain the benefits of instant transactions, credit, and anti-fraud, bitcoin overall would enjoy improved scaling from offloaded transaction volume without compromising its decentralized nature. In a world where bitcoin was widely used payment processing systems would probably have lower prices because they would need to compete with raw-bitcoin transactions, they also could be afford lower price because frequent bitcoin settling (and zero trust bitcoin escrow transactions) would reduce their risk. This is doubly true because bitcoin could conceivably scale to replace them entirely, even if that wouldn't be the best idea due to the resulting reduction in decentralization.

	==Scalability targets==		==Scalability targets==

Gmaxwell: note that this page is hopefully outdated.

2016-07-06T06:30:17Z

note that this page is hopefully outdated.

← Older revision		Revision as of 06:30, 6 July 2016
Line 1:		Line 1:
			[Note: This page is seriously outdated and largely unmaintained; due to past incidents of edit-warring it has not been subject to much peer review.]

	A Bitcoin full node could be modified to scale to much higher transaction rates than are seen today, assuming that said node is running on a high end servers rather than a desktop. Bitcoin was designed to support lightweight clients that only process small parts of the block chain (see ''simplified payment verification'' below for more details on this).		A Bitcoin full node could be modified to scale to much higher transaction rates than are seen today, assuming that said node is running on a high end servers rather than a desktop. Bitcoin was designed to support lightweight clients that only process small parts of the block chain (see ''simplified payment verification'' below for more details on this).

	''Please note that this page exists to give calculations about the scalability of a Bitcoin full node and transactions on the block chain without regards to network security. It is not intended to discuss the scalability of alternative protocols or try and summarise philosophical debates. Create alternative pages if you want to do that.''		''Please note that this page exists to give calculations about the scalability of a Bitcoin full node and transactions on the block chain without regards to network security and decentralization. It is not intended to discuss the scalability of alternative protocols or try and summarise philosophical debates. Create alternative pages if you want to do that.''

	==Scalability targets==		==Scalability targets==

Gmaxwell: /* CPU */ rm misinformation wrt ed25519. libsecp256k1 is now widely used in Bitcoin-- with options on it's considerably faster than ed25519 donna. The curve Bitcoin uses was specifically constructed for high speed and is very hard to beat in that respect

2016-07-06T06:24:18Z

CPU: rm misinformation wrt ed25519. libsecp256k1 is now widely used in Bitcoin-- with options on it's considerably faster than ed25519 donna. The curve Bitcoin uses was specifically constructed for high speed and is very hard to beat in that respect

← Older revision		Revision as of 06:24, 6 July 2016
Line 53:		Line 53:
	===CPU===		===CPU===

	Pieter Wuille has implemented a custom verifier tuned for secp256k1 that can go beyond 20,000 signature verifications per second. It would require careful review by professional cryptographers to gain as much confidence as OpenSSL, but this can easily halve CPU load.		Algorithms exist to accelerate batch verification over elliptic curve signatures. It's possible to check their signatures simultaneously for a 2x speedup. This is a somewhat more complex implementation.

	Algorithms exist to accelerate batch verification over elliptic curve signatures. ~~This means if there are several inputs that are signing with the same key, it~~'s possible to check their signatures simultaneously for ~~another 9x~~ speedup. This is a somewhat more complex implementation~~, however, it can work with existing signatures (clients don't need upgrading).~~

	Newly developed digital signature algorithms, like [http://ed25519.cr.yp.to/ed25519-20110705.pdf ed25519] have extremely efficient software implementations that can reach speeds of nearly 80,000 verifications per second, even on an old Westmere CPU. That is a 10x improvement over secp256k1, and most likely is even higher on more modern CPUs. Supporting this in Bitcoin would mean a chain fork. This ECC algorithm has also been shown to be [http://eprint.iacr.org/2014/198 easily accelerated using GPUs], yielding scalar point multiplication times of less than a microsecond (i.e. a million point multiplications per second).

	~~At these speeds it is likely that disk and memory bandwidth would become the primary limiting factor, rather than signature checking~~.

	===Simplified payment verification===		===Simplified payment verification===