ok, so I have a plan for the light client privacy question
so client gets notice that there is a new block
it asks for the top layers of utxo
the intermediate hash nodes that are different from what the client already knows about and might contain addresses that are interesting to the client, the client will ask about
the client should have a set of actual address, consistent fake addresses and dynamic fake addresses
the consistent fake addresses make it hard to see what a client is really interested in
the dynamic fake addresses make it harder to fingerprint a client based on what they are asking about
the client will try to get to the leaf nodes in big chunks to further disguise what they are into
for example, if they address they are interested is 0xaabbccddeeff the client will ask for 0xaabbcc
it might have to do an additional question if there are too many things under that, but it depends on how full the tree is
i haven't worked out the math yet
probably has the same problems as the bloomfilter method that everyone hates now, but certainly better than nothing
it is also quite efficient, since the client can cache any intermediate hash nodes that it sees
since the things under them can never change
so basically, the client does not want the node to know which address its asking for. To obfuscate things a little, it tells the node: "Its something like this". Then the node returns results for all addresses that are possible
As more addresses are in use, the client has to ask more precise. But the client does not know how precise. If it asks the node, it could tell the client "give me first 8 bytes", which reveals the address, although 2 bytes would have been sufficient.
What about this: The light client can also act as a node to other light clients. If it gets asked, it just relays the request to its node. This way the node does not know where the request originated from
yeah, think of it as asking for information on all addresses that start with X and if that returns too many results it might have to ask again with a slightly closer thing, but if that is the case it means there is still a bunch of addresses that it could be
relaying other requests is an interesting idea
just throws more mud
and even if there are only a few in the prefix, there is a good change the client isn't even interested in any of those
and it is an address that has never been used
but one of these addresses is a real, used one?
any address in a utxo query return is real
but the client may be interested in an address that has never been used
can never be sure
well, until the client sends a signed transaction
is it even worth the effort?
Probably
Just effort for me. Should be transparent after that.