How much information is passed from the daemon to simplewallet when scanning for a wallet's transactions?

Question

When simplewallet is connected to a local daemon, the data throughput is mostly irrelevant because communication is done completely locally. But I am curious about how much data/information is transferred between a remote node and simplewallet?

For example: Let's say simplewallet needs to update your wallet for the last 720 blocks (1 day). Let's also say that over that span blocks are averaging 10 txs/block and 1.5 kB/tx, or 15 kB/block. Finally, let's say that 10 txs belong to your wallet over that span. How much data would be used by simplewallet? Is any block information not shared with simplewallet?

---

Edit 16 Sept 2016:

I'm going to be a little more specific in my question, and also add a bounty, as I'd like to know the specifics but also recognize that this will require a bit of work.

In general, the following information is available in a block (I may be missing some info and am happy to add/correct this list):

• blob
• block header
  • depth
  • difficulty
  • hash
  • height
  • major_version
  • minor_version
  • nonce
  • orphan_status
  • prev_hash
  • reward
  • timestamp
• miner_tx
  • version
  • unlock_time
  • vin / gen / height
  • vout w/ each output (amount, target key)
• extra
• signatures
• all transactions in block
  • all details of transactions (hashes, key amounts, key offsets, key images, tx extra, siganatures, etc)

Questions:

1. Does simplewallet receive all of this information from the daemon for every block (and all transactions in the block) or only a subset of this information?

2. In either case, is there information that simplewallet does currently receive that it does not always need (for example, if the transaction does not belong to a wallet) and therefore sending that information could have been avoided if designed to minimize data transfer?

---

EDIT 17 Oct 2016: I've decided to spin off the last part of this question into a new question as it is fairly different in scope.

Follow-up question for those keeping track: Is it possible to create a lighter wallet than simplewallet without giving up a view key?

Answer 1

I captured the stream of RPC requests and answers between monero-wallet-cli and monerod (v0.10) with wireshark to see how much data is transferred during a synchronization.

It was a synchronization of 658 blocks (blocks 1159032 to 1159659), and the total amount of data exchanged was:

• 7662 bytes from the wallet to the daemon (get_version, getblocks.bin, get_transaction_pool and gettransactions requests)
• 5912493 bytes from the daemon to the wallet (almost all of which was answers to the getblocks.bin requests)

It means that on average the daemon sent between 8 kB and 9 kB of data per block to synchronize (RPC headers and JSON formatting included). I looked at the last 20 blocks of the synchronization and their average size is around 6 kB. In fact, the daemon sends the complete blocks to the wallet, and the wallet checks all the transactions in the received blocks to find its own.

Answer 2

This was kind of already answered in this question. Therefore, I'll quote the answer provided by user36303 there.

Q: What are the risks in using the same daemon

A: They're typically small, and mostly either privacy leaks or denial of service.

Obviously, whoever runs the daemon may either withhold new blocks, and try to inject fake blocks. The wallet will not check PoW, etc. A daemon who knows the user's standard address could make a transaction to that address, not relay it to the network as a whole, mine it, and make it seem the user was paid.

Privacy leaks exist, and most of them can be plugged by not using --trusted-daemon (however, if you're connecting to a node on the local machine, the daemon is assumed trusted. If you're on the same machine, you have bigger problems anyway, see below).

First, when sending a transaction, the wallet will request random outputs from the daemon to use in a ring signature. This means that, when the wallet sends the transaction, the daemon will see the outputs it sent earlier, plus another one. That must be the real output, which the wallet already knew about. This is fixed in the rct branch: the wallet then decides which outputs to get, and include its own there, so the daemon cannot tell which is which.

When refreshing the wallet, a block containing one more more outputs for that wallet will cause a request to the daemon for more information about this transaction. This tells the daemon that this transaction has at least one outout for the wallet. This is fixed in the rct banch, where this information is sent with all blocks in the first place, so the daemon cannot tell which transaction pay the wallet.

When sending a transaction, the wallet will ask the daemon for the number of outputs of given size exist on the blockchain, to know what amounts are compatible with the requested mixin. This tells the daemon the set of amounts for which the wallet has one more more outputs. If using an untrusted daemon, this will be skipped (the wallet will ask for all outputs, not just the ones it has; it's fairly slow, but privacy preserving).

In any case, the daemon never gets anywhere the wallet's private keys, whether spend or view.

Last, if the wallet connects to an untrusted daemon, then the daemon may try to attack the wallet through an buffer overflow or other bug. Hopefully there aren't any, but then most software hopes so too.