Please login or register.
This location

Lightweight client architecture / software

Gingeropolous posted this 9 years ago

Gingeropolous | 9 years ago

This has been mentioned before, and it seems doable. The proposal is a lightweight node, probably used on a mobile phone. First, it is set up on a computer running a full node - all of the owners outputs are extracted from the blockchain to create miniblockchain A. Then, random blocks from blockchain are added to miniblockchain B to create a mixin set. This miniblockchain is then transferred to the phone. The wallet software can then create transactions using this minimal blockchain.

We would need to figure out how to keep the minimal blockchains syncd with a true blockchain if the owner uses their account on a lightweight AND full node. If the owner only uses the account on the lightweight node, it can be assumed that whatever transactions are performed local on the device will mimic what happens global on the blockchain. On the other hand, if the owner does something on the global blockchain, the lightweight clients minimal blockchains will need to be updated. Though perhaps this could be fixed by having the phone function similarly to a full node, but it only keeps the last 1000 blocks.

So, in a lightweight node, their would be a miniblockchain comprised of these 3 sub-blockchains:

A. Owners collection of outputs
B. Random selection mixin set
C. Last 1000 blocks

The last 1000 blocks is scanned to identify new outputs of the owner and store in set A, and occasionally grab "good looking" outputs to include in set B. 1000 blocks is used for security, re: reorgs etc. In actuality, the lightweight client would probably just scan block #(current blockheight - 1000) for items to move to set A or B.

Replies: 4
EhVedadoOAnonimato edited 9 years ago Replies: 1 | Weight: -149 | Link [ - ]

The only problem with your idea that I see is this requires the lightweight node to download, even if it doesn't store, all transactions.

That was how Bitcoin first lightweight node, bitcoinj, used to behave. That started to become a problem for mobile nodes, as the amount of data to download was getting bigger. The solution was the usage of bloom filters, allowing the lightweight nodes to only download the data that concerned them. You can set a high rate of false positive to bloom filters, and you can request different subsets of your keys to different peers, in order to protect your privacy. Unfortunately, for this solution to be applicable to Monero, full nodes would have to be able to serve bloom filter requests.

Actually, the requesting different subsets of keys would also be important when building the mixin set. I think it would be better to renew the set of keys to be used at each transaction, in order to never reuse two keys given by the same peer for the same request. Don't keep connections open in between different requests/transactions and hide your IP behind Tor or I2P before connecting to full nodes. All these measures are to prevent full nodes from breaking your unlinkability.

Edit: I'm thinking this through again. Keeping Monero's privacy features for a lightweight node is not an easy thing. The reason I'm saying this is that I believe that, as the pool of available keys for mixin increases, any response for a request of keys for a mixin would look more and more like a fingerprint. The likelihood of two different request being identical is probably already very small right now. And eventually, the chance of any two different requests having any intersection at all between their keys would probably be very small. So, suppose your lightweight node requests keys to different full nodes for a mixin. As per the assumption, there's a very little chance of any intersection between the sets. So, as soon as you push a transaction that contains one key provided to you by full node F, F would know with good probability that that transaction belongs to that lightweight node it had given that key in the past. And for this reason F would know the key it has given is not the true one. If F managed to collude with every other node that provided all the mixin keys used (Sybil attack), the collusion would be able to infer the true key. Perhaps adding keys returned as false positive for the bloom filter requests would help, since the true input is known to be part of it. Actually, thinking again, you must reuse keys from the bloom filter, because the bloom filter response itself may eventually become close to a fingerprint! Damn... that makes it even worse. If the false results of bloom filter requests are not used systematically in the mixin, the node which provided you with your output would always know when you spend it. It makes me wonder if bloom filters are a good idea at all. OTOH, there must be a way to reduce bandwidth demands for lightweight wallets, and besides bloom filters I don't know any other way.

The use of networks like Tor or I2P become even more important, since the attacker would have to kinda of break those networks in order to Sybil attack you. That raises the bar considerably.

Reply to: EhVedadoOAnonimato
Gingeropolous edited 9 years ago Replies: 1 | Weight: -147 | Link [ - ]

> allowing the lightweight nodes to only download the data that concerned them

right. one workaround for this is to only use your mobile-associated xmr address on your lightweight client. this way, theres no reason to continually dload data. anything relevant to this account occurs locally, from the phone. Sure, you would need to have some kind of special sycn process at home to add more outputs to your phone, but thats fine. Basically, we try to mimic an actual wallet full of cash. You dont walk around with your checking accounts worth of cash in your wallet. And also, when money gets deposited in your checking account, cash doesnt magically appear in your wallet. While we may toute the ability to have instant access to everything as awesome, is it ultimately the safest approach?

regarding the fingerprint concern, i think this could be addressed without complicated solutions. a 10mb collection of blocks would have a lot of transactions. these liitle packets could be dloaded easily, randomly, and at any time. And these tiny packets could be served up by either some service (similar to the architecture of electrum) or could be incorporated into monero core. In either case, they only fingerprint that might be possible is that you could determine whether a transaction was made from a light node vs. a full node.

Reply to: Gingeropolous EhVedadoOAnonimato
EhVedadoOAnonimato posted 9 years ago Replies: 1 | Weight: -145 | Link [ - ]

I'm not sure I understood your solution for the low bandwidth case. Suppose we meet in meatspace and you send me a payment, to my phone. How will I know when the payment is settled (confirmed)? Either I'm downloading all the data (unfeasible in the long run), or I'm using some kind of filter. I cannot wait to get home and sync, that would be bad UX.

Your suggestion for the "fingerprint" is to have a large enough set of outputs, in order to be sure there's enough probability other lightweight wallets would have intersections with you. 10mb might not be large enough if the chain is really big, but it's true that the larger the chain, the larger the expected number of lightweight wallets out there. So perhaps your solution is feasible. Specially because you only need to download this larger set of data, you don't really need to store it.

Reply to: EhVedadoOAnonimato Gingeropolous EhVedadoOAnonimato
Gingeropolous posted 9 years ago Weight: -144 | Link [ - ]

How about this - in that case you speak of, you could just turn your phone-node into full-listen mode. So, just for those 5-10 minutes that it might take for the transaction to be confirmed, your phone is gobbling data. Then, when you're done, you switch your phone-node back to random-listen mode. This might expose you to some kind of information leak if an evildoer is monitoring your phones data connection and records when it starts dloading in full listen mode and then parses those blocks for data blah blah blah.

and the 10 mb i mentioned would be repeated - i.e., my phone would download 5 X 10 MB chunks randomly throughout the day. Keeps some, deletes others... the next day, it does it again.