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:
This is only the logic structure. The actually data is encoded in RLP format, thus is longer due to the added length prefix.
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:
- 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.
- 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).
- 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".