Alice owns an empty Ethereum wallet. Receives 1 ETH then sends 1 ETH to Bob.

Alice owns an empty Bitcoin wallet. Receives 1 BTC then sends 1 BTC to Bob.

What are the transaction sizes in bytes (Alice->Bob) in both cases? If Ethereum is lower, is that the main reason why Ethereum can do more tx/sec than bitcoin?

This post contains several questions. Let's address them one by one.

Before answering the questions, there is an error in the post's assumption: it doesn't consider the transaction fees. If Alice has one Ether or one BTC, Bob won't be able to receive the full amount (maybe he could, back in the days of zero transaction fees for BTC, but certainly not now), as the transaction fees need to be deducted from Alice's account.

Size of a simple Ethereum transaction

From the Ethereum yellow paper, we know the a transaction's logical structure is as follows.

-----------------------------
| Nonce    | Up to 32 bytes |
-----------------------------
| GasPrice | Up to 32 bytes |
-----------------------------
| GasLimit | Up to 32 bytes |
-----------------------------
| To       | 20 bytes addr  |
-----------------------------
| Value    | Up to 32 bytes |
-----------------------------
| Data     | 0 - unlimited  |
-----------------------------
| V        | 1 (usually)    |
-----------------------------
| R        | 32 bytes       |
-----------------------------
| S        | 32 bytes       |
-----------------------------

Note:

  1. This is only the logic structure. The actually data is encoded in RLP format, thus is longer due to the added length prefix.

  2. The V field was always 1 byte before EIP-155. It's probably safe to say every major client has implemented EIP-155. For the main net, test net, this field stays as 1 byte even with EIP-155. For private networks with "chain ID" of larger values, this field can be much longer. See this question.

We could use ridiculous data to give a theoretical "minimum" size, e.g. by giving zero gas price. However, that's not very meaningful as such transactions wouldn't be able to get mined these days. Instead, we use this transaction as a sample for analysis, as it is a realistically simple Alice-to-Bob payment.

From web3 console, execute the following (depending on the client, might need to use 'eth.getRawTransaction' instead)

eth.getTransaction(''0x14a298c1eea89f42285948b7d51eeac2876ca7406c9784b9b90dd3591d156d64').raw

This should give

"0xf86b80850ba43b7400825208947917bc33eea648809c285607579c9919fb864f8f8703baf82d03a0008025a0067940651530790861714b2e8fd8b080361d1ada048189000c07a66848afde46a069b041db7c29dbcc6becf42017ca7ac086b12bd53ec8ee494596f790fb6a0a69"

which is 109 bytes. If we parse the data

f86b length 80 nonce (0: this is the minimum an account can have) 85 0ba43b7400 gas price 82 5208 gas limit (this is fixed for simple payments) 94 7917bc33eea648809c285607579c9919fb864f8f (address, always 20 bytes) 87 03baf82d03a000 (value, in theory this can be shrunken to zero) 80 (data, already zero length) 25 (V, one byte) a0 067940651530790861714b2e8fd8b080361d1ada048189000c07a66848afde46 (R) a0 69b041db7c29dbcc6becf42017ca7ac086b12bd53ec8ee494596f790fb6a0a69 (S)

From this sample, there isn't much more to be shortened. A smaller value can reduce the value field to one byte. Lower gas price may shrink one or two bytes further. Thus it seems a realistic "minimum" transaction size is should be greater than 100 bytes (109 - 7 -2).

Size of a simple Bitcoin transaction

Things are more complicated for a Bitcoin transaction (structure explained here). Assume the "classic" transaction, i.e. no SegregatedWitness:

  1. A Bitcoin transaction always references its previous UTXO (unspent transaction) hashes. The simple assumption "Alice receives 1 BTC" doesn't imply how many UTXO sums up to that 1 BTC. It can range from 1 to any number.
  2. In a similar way, the assumption "Alice pays Bob 1 BTC" doesn't imply the number of transaction outputs. There may be only 1 output, meaning any remaining balance goes to the miner, or arbitrary number of outputs, with Alice's remaining balance divided into multiple "legs" (outputs).
  3. Things get more complicated when we consider the scriptSig and scriptPubKey (as said, assume no SegWit). Alice's UTXOs may consist of a simple P2PKH script, or multi-sig, or P2SH, or, in the extreme case, a silly "anyone can spent" script (see example here). The same is true for the transaction outputs, multiplying the number of possible combinations in the above two points, too many possibilities then comes up.

For a rough estimate, probably a good sample transaction is the one described in this awesome blog post, the number of bytes is 247.

is that the main reason why Ethereum can do more tx

This question assumes Ethereum's block size limit is determined by byte length. This isn't true. The block size is actually determined by the block's gas limit. See this question for more details. So the simple answer to this question is "no".

Let's do a quick back of the envelope estimation for the average transaction size on the Ethereum network.

Simplifying assumptions:

  • Most of the block size if occupied by transactions
  • Most of transactions are simple transactions which just transfer ether (this assumption is questionable I know...)


Calculus:

  • Average # of transactions in an hour ~ 20,000
  • Average # blocks per hour = 261
  • => 20,000/261 ~ 76 transactions per block on average
  • => 15kb/76 ~ 0.2kb

Average transaction size for bitcoin ~ 0.6kb (3x time more than Ethereum)

So yes, Ethereum transactions are smaller on average but it does not explain alone the superior processing capacity. A major difference bitcoin Bitcoin and Ethereum is that Ethereum does not have a block size limit per se, but instead has a gas limit, i.e it can execute only a maximum amount of computations. So depending on how big transactions and how computationally intensive transactions are, an Ethereum block can fit more or less transactions. Another consideration is that for Ethereum the target block time is ~ 17s vs 10mins for Bitcoin.

Sources:

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.