Maximum transaction rate: Difference between revisions
m s/MiB/MB/ |
clarified what "Maximum transaction rate" the article is about |
||
| (4 intermediate revisions by one other user not shown) | |||
| 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# | 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: | scriptPubKey: <33 byte compressed pubKey> OP_CHECKSIG | ||
scriptSig: <72 byte signature | 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 | 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 | 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 | 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 | 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/> | ||
Latest revision as of 19:27, 14 January 2014
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[1] is the OP_CHECKSIG transaction:
scriptPubKey: <33 byte compressed pubKey> OP_CHECKSIG 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 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 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 156 byte average transactions, or 10.7tx/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 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.
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
- ↑ Even smaller transactions can be made by using empty scriptPubKeys, however such transactions are not secure because anyone can spend them.