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?

  • 2
    Everything is passed. Current simplewallet discards the signatures, but may still want to verify them, if the node is not trusted. You could get away with passing less if the wallet trusts the node. An extreme could be to send the daemon your private view key, and receive just outputs that are for you (pretty lightweight, but pretty bad for privacy). – user36303 Sep 18 '16 at 10:04
  • 2
    anyone cares to do a test? Suggestion: set-up some kind of network monitoring, start daemon+wallet and perform a full refresh until x height, and tell us how much data was used. Describe the process used. – JollyMort Oct 17 '16 at 11:00
  • I'm hopeful someone takes you up on your bounty. I had one open a few weeks ago and all I got was crickets. – bigreddmachine Oct 17 '16 at 14:12
up vote 6 down vote accepted
+200

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.

  • Thanks for doing the investigative legwork here. I'm going to mark this as the correct answer, and spin off the second part of my question into a new question – bigreddmachine Oct 17 '16 at 21:21
  • That second part being "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?" – bigreddmachine Oct 17 '16 at 21:21
  • 2
    Cool, I think this is what we've been looking for. Thanks for doing it! (need to wait 13 more hours before I can release the bounty, though) – JollyMort Oct 17 '16 at 21:52

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.

  • 5
    I agree that this is relevant, but it dances around any specifics. The motivation for the question is to understand how "light" something like Lightwallet actually is, and ultimately if something similar to it could be deployed on mobile. I don't include the motivation in the question because I don't want to distract from the question: How much data is sent to the wallet compared to the total data that actually exists in the blocks? I appreciate the reply though. – bigreddmachine Sep 7 '16 at 16:59

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.