Maximum transaction rate - Revision history

Giszmo: clarified what "Maximum transaction rate" the article is about

2014-01-14T19:27:18Z

clarified what "Maximum transaction rate" the article is about

← Older revision		Revision as of 19:27, 14 January 2014
Line 21:		Line 21:

	Actual real-world rates will likely be somewhere between those numbers, although equally rates may be less as well if multi-signature transactions are become popular; the figure 7tx/s is commonly quoted as a 'ball-park' approximation in discussions of the [[Scalability\|blocksize limit]].		Actual real-world rates will likely be somewhere between those numbers, although equally rates may be less as well if multi-signature transactions are become popular; the figure 7tx/s is commonly quoted as a 'ball-park' approximation in discussions of the [[Scalability\|blocksize limit]].

			== The Bitcoin system vs. the Bitcoin blockchain ==

			Numbers discussed here apply to the bitcoin blockchain and are no hard limits to the bitcoin system in a broader sense. Off chain transactions, most notably transaction channels allow arbitrary transaction rates with instant, off the chain (added privacy), secure micro-transactions.

	== Footnotes ==		== Footnotes ==
	<references/>		<references/>

Petertodd: /* Trust-free Combining */

2013-04-14T11:13:16Z

Trust-free Combining

← Older revision		Revision as of 11:13, 14 April 2013
Line 14:		Line 14:
	== Trust-free Combining ==		== Trust-free Combining ==

	Users can also combine their transactions to make them slightly smaller, and possibly improve privacy. A transaction is invalid until every transaction input is signed for, thus multiple users can create a joint transaction with no risk of their funds being stolen. This reduces average transaction size by 10 bytes; the size of the per-transaction header. Using this technique aggressively results in 156 byte average transactions, or 10.7tx/s.		Users can also combine their transactions to make them slightly smaller, and possibly improve privacy. A transaction is invalid until every transaction input is signed for, thus multiple users can create a joint transaction with no risk of their funds being stolen. This reduces average transaction size by 10 bytes, the size of the per-transaction header. Using this technique aggressively results in 156 byte average transactions, or 10.7tx/s.

	== Lower-bound transaction rate ==		== Lower-bound transaction rate ==

Petertodd: /* Lower-bound transaction rate */

2013-04-14T11:12:52Z

Lower-bound transaction rate

← Older revision		Revision as of 11:12, 14 April 2013
Line 20:		Line 20:
	A reasonable, conservative, assumption is to assume that every transaction requires two outputs, including change, and two inputs, consuming change. Assuming that trust-free combining is not used gives us 322 byte transactions, or 5.2tx/s.		A reasonable, conservative, assumption is to assume that every transaction requires two outputs, including change, and two inputs, consuming change. Assuming that trust-free combining is not used gives us 322 byte transactions, or 5.2tx/s.

	Actual real-world rates will likely be somewhere between those numbers, although equally rates may be less as well if multi-signature transactions are become popular; the figure 7tx/s is commonly quoted as a 'ball-park' approximation in discussions of the [[blocksize limit]].		Actual real-world rates will likely be somewhere between those numbers, although equally rates may be less as well if multi-signature transactions are become popular; the figure 7tx/s is commonly quoted as a 'ball-park' approximation in discussions of the [[Scalability\|blocksize limit]].

	== Footnotes ==		== Footnotes ==
	<references/>		<references/>

Petertodd: Add ball-park figure

2013-04-14T11:11:55Z

Add ball-park figure

← Older revision		Revision as of 11:11, 14 April 2013
Line 20:		Line 20:
	A reasonable, conservative, assumption is to assume that every transaction requires two outputs, including change, and two inputs, consuming change. Assuming that trust-free combining is not used gives us 322 byte transactions, or 5.2tx/s.		A reasonable, conservative, assumption is to assume that every transaction requires two outputs, including change, and two inputs, consuming change. Assuming that trust-free combining is not used gives us 322 byte transactions, or 5.2tx/s.

	Actual real-world rates will likely be somewhere between those numbers, although equally rates may be less as well if multi-signature transactions are become popular.		Actual real-world rates will likely be somewhere between those numbers, although equally rates may be less as well if multi-signature transactions are become popular; the figure 7tx/s is commonly quoted as a 'ball-park' approximation in discussions of the [[blocksize limit]].

	== Footnotes ==		== Footnotes ==
	<references/>		<references/>

Petertodd: Re-calculate for pure OP_CHECKSIG tx's

2013-02-25T19:39:33Z

Re-calculate for pure OP_CHECKSIG tx's

← Older revision		Revision as of 19:39, 25 February 2013
Line 1:		Line 1:
	The maximum transaction rate is the block size limit divided by the average transaction size. The block size limit is well known, 1MB, however the average transaction size isn't. Here we'll look at what influences that size.		The maximum transaction rate is the block size limit divided by the average transaction size. The block size limit is well known, 1MB, however the average transaction size isn't. Here we'll look at what influences that size.

	The minimum sized transaction type<ref name="mintxsize">Even smaller transactions can be made by using empty scriptPubKeys, however such transactions are not secure because anyone can spend them.</ref> is the [[Script#~~Standard_Transaction_to_Bitcoin_address~~\|~~standard~~ transaction]]:		The minimum sized transaction type<ref name="mintxsize">Even smaller transactions can be made by using empty scriptPubKeys, however such transactions are not secure because anyone can spend them.</ref> is the [[Script#Standard_Generation_Transaction\|OP_CHECKSIG transaction]]:

	scriptPubKey: ~~OP_DUP OP_HASH160~~ <20 byte ~~pubKeyHash~~> ~~OP_EQUALVERIFY~~ OP_CHECKSIG		scriptPubKey: <33 byte compressed pubKey> OP_CHECKSIG
	scriptSig: <72 byte signature~~> <33 byte compressed pubKey~~>		scriptSig: <72 byte signature>

	Each transaction input requires at least 41 bytes for the previous transaction reference and other headers and each transaction output requires an additional 9 bytes of headers. Finally every transaction has a header at least 10 bytes long. Added up we get ~~189~~ bytes for the minimum-sized Bitcoin transaction. For 1MB (1,000,000 byte) blocks this implies a theoretical maximum rate of ~~8.8tx~~/s.		Each transaction input requires at least 41 bytes for the previous transaction reference and other headers and each transaction output requires an additional 9 bytes of headers. Finally every transaction has a header at least 10 bytes long. Added up we get 166 bytes for the minimum-sized Bitcoin transaction. For 1MB (1,000,000 byte) blocks this implies a theoretical maximum rate of 10tx/s.

	However [[Change\|change]] complicates the situation. It isn't always possible for a client to find a transaction input of the size required. Thus client software will included additional outputs to themselves for the change, and similarly they will include additional inputs to collect change outputs together when no one output is large enough.		However [[Change\|change]] complicates the situation. It isn't always possible for a client to find a transaction input of the size required. Thus client software will included additional outputs to themselves for the change, and similarly they will include additional inputs to collect change outputs together when no one output is large enough.
Line 14:		Line 14:
	== Trust-free Combining ==		== Trust-free Combining ==

	Users can also combine their transactions to make them slightly smaller, and possibly improve privacy. A transaction is invalid until every transaction input is signed for, thus multiple users can create a joint transaction with no risk of their funds being stolen. This reduces average transaction size by 10 bytes; the size of the per-transaction header. Using this technique aggressively results in ~~179~~ byte average transactions, or 9.~~3tx~~/s.		Users can also combine their transactions to make them slightly smaller, and possibly improve privacy. A transaction is invalid until every transaction input is signed for, thus multiple users can create a joint transaction with no risk of their funds being stolen. This reduces average transaction size by 10 bytes; the size of the per-transaction header. Using this technique aggressively results in 156 byte average transactions, or 10.7tx/s.

	== Lower-bound transaction rate ==		== Lower-bound transaction rate ==

	A reasonable, conservative, assumption is to assume that every transaction requires two outputs, including change, and two inputs, consuming change. Assuming that trust-free combining is not used gives us ~~368~~ byte transactions, or 4.~~5tx~~/s.		A reasonable, conservative, assumption is to assume that every transaction requires two outputs, including change, and two inputs, consuming change. Assuming that trust-free combining is not used gives us 322 byte transactions, or 5.2tx/s.

	Actual real-world rates will likely be somewhere between those numbers, although equally rates may be less as well if ~~multisignature~~ transactions are become popular.		Actual real-world rates will likely be somewhere between those numbers, although equally rates may be less as well if multi-signature transactions are become popular.

	== Footnotes ==		== Footnotes ==
	<references/>		<references/>

Petertodd: s/MiB/MB/

2013-02-24T20:39:33Z

s/MiB/MB/

← Older revision		Revision as of 20:39, 24 February 2013
Line 1:		Line 1:
	The maximum transaction rate is the block size limit divided by the average transaction size. The block size limit is well known, ~~1MiB~~, however the average transaction size isn't. Here we'll look at what influences that size.		The maximum transaction rate is the block size limit divided by the average transaction size. The block size limit is well known, 1MB, however the average transaction size isn't. Here we'll look at what influences that size.

	The minimum sized transaction type<ref name="mintxsize">Even smaller transactions can be made by using empty scriptPubKeys, however such transactions are not secure because anyone can spend them.</ref> is the [[Script#Standard_Transaction_to_Bitcoin_address\|standard transaction]]:		The minimum sized transaction type<ref name="mintxsize">Even smaller transactions can be made by using empty scriptPubKeys, however such transactions are not secure because anyone can spend them.</ref> is the [[Script#Standard_Transaction_to_Bitcoin_address\|standard transaction]]:

Petertodd: s/MiB/MB/

2013-02-24T20:39:12Z

s/MiB/MB/

← Older revision		Revision as of 20:39, 24 February 2013
Line 6:		Line 6:
	scriptSig: <72 byte signature> <33 byte compressed pubKey>		scriptSig: <72 byte signature> <33 byte compressed pubKey>

	Each transaction input requires at least 41 bytes for the previous transaction reference and other headers and each transaction output requires an additional 9 bytes of headers. Finally every transaction has a header at least 10 bytes long. Added up we get 189 bytes for the minimum-sized Bitcoin transaction. For ~~1MiB~~ blocks this implies a theoretical maximum rate of 8.8tx/s.		Each transaction input requires at least 41 bytes for the previous transaction reference and other headers and each transaction output requires an additional 9 bytes of headers. Finally every transaction has a header at least 10 bytes long. Added up we get 189 bytes for the minimum-sized Bitcoin transaction. For 1MB (1,000,000 byte) blocks this implies a theoretical maximum rate of 8.8tx/s.

	However [[Change\|change]] complicates the situation. It isn't always possible for a client to find a transaction input of the size required. Thus client software will included additional outputs to themselves for the change, and similarly they will include additional inputs to collect change outputs together when no one output is large enough.		However [[Change\|change]] complicates the situation. It isn't always possible for a client to find a transaction input of the size required. Thus client software will included additional outputs to themselves for the change, and similarly they will include additional inputs to collect change outputs together when no one output is large enough.

Petertodd: First version

2013-02-24T20:38:34Z

First version

New page

The maximum transaction rate is the block size limit divided by the average transaction size. The block size limit is well known, 1MiB, however the average transaction size isn't. Here we'll look at what influences that size.

The minimum sized transaction type<ref name="mintxsize">Even smaller transactions can be made by using empty scriptPubKeys, however such transactions are not secure because anyone can spend them.</ref> is the [[Script#Standard_Transaction_to_Bitcoin_address|standard transaction]]:

scriptPubKey: OP_DUP OP_HASH160 <20 byte pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <72 byte signature> <33 byte compressed pubKey>

Each transaction input requires at least 41 bytes for the previous transaction reference and other headers and each transaction output requires an additional 9 bytes of headers. Finally every transaction has a header at least 10 bytes long. Added up we get 189 bytes for the minimum-sized Bitcoin transaction. For 1MiB blocks this implies a theoretical maximum rate of 8.8tx/s.

However [[Change|change]] complicates the situation. It isn't always possible for a client to find a transaction input of the size required. Thus client software will included additional outputs to themselves for the change, and similarly they will include additional inputs to collect change outputs together when no one output is large enough.

Users with large wallets, in particular [[eWallets]] such as Instawallet or large exchanges like Mt. Gox are most likely to be able to find transaction outputs of a suitable size for any given payment. It's conceivable that if transaction fees are high enough in the future users who trust each other may get together to use each others wallets to make payments as a way to avoid transaction fees, with the balances settled periodically by some other means.

== Trust-free Combining ==

Users can also combine their transactions to make them slightly smaller, and possibly improve privacy. A transaction is invalid until every transaction input is signed for, thus multiple users can create a joint transaction with no risk of their funds being stolen. This reduces average transaction size by 10 bytes; the size of the per-transaction header. Using this technique aggressively results in 179 byte average transactions, or 9.3tx/s.

== Lower-bound transaction rate ==

A reasonable, conservative, assumption is to assume that every transaction requires two outputs, including change, and two inputs, consuming change. Assuming that trust-free combining is not used gives us 368 byte transactions, or 4.5tx/s.

Actual real-world rates will likely be somewhere between those numbers, although equally rates may be less as well if multisignature transactions are become popular.

== Footnotes ==
<references/>