{"type":"rich","version":"1.0","author_name":"npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","author_url":"https://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-03-27\n📝 Original message:\u003e\n\u003e One issue that I have is bandwidth: Electrum (and mycelium) cannot\n\u003e watch as many addresses as they want, because this will create too\n\u003e much traffic on the servers. (especially when servers send utxo merkle\n\u003e proofs for each address, which is not the case yet, but is planned)\n\u003e\n\nThis is surprising and the first time I've heard about this. Surely your\nconstraint is CPU or disk seeks? Addresses are small, I find it hard to\nbelieve that clients uploading them is a big drain, and mostly addresses\nthat are in the lookahead region won't have any hits and so won't result in\nany downloads?\n\nThis constraint is not so important for bloom-filter clients.\n\n\nBloom filters are a neat way to encode addresses and keys but they don't\nmagically let clients save bandwidth. A smaller filter results in less\nupload bandwidth but more download (from the wallets perspective). So I'm\nworried if you think this will be an issue for your clients: I haven't\ninvestigated bandwidth usage deeply yet, perhaps I should.\n\nFWIW the current bitcoinj HDW alpha preview pre-gens 100 addresses on both\nreceive and change branches. But I'm not sure what the right setting is.\n\nWe also have to consider latency. The simplest implementation from a\nwallets POV is to step through each transaction in the block chain one at a\ntime, and each time you see an address that is yours, calculate the next\nones in the chain. But that would be fantastically slow, so we must instead\npre-generate a larger lookahead region and request more data in one batch.\nThen you have to recover if that batch ends up using all the pre-genned\naddresses. It's just painful.\n\n\n\u003e My opinion, as far as Electrum is concerned, is that merchant accounts\n\u003e should behave differently from regular user accounts: While merchants\n\u003e need to generate an unlimited number of receiving addresses, it is also\n\u003e acceptable for them to have a slightly more complex wallet recovery\n\u003e procedure\n\u003e\n\nMaybe. I dislike any distinction between users and merchants though. I\ndon't think it's really safe to assume merchants are more sophisticated\nthan end users.\n\n\n\u003e but also because we want fully automated synchronization between different\n\u003e instances of a wallet, using only no other source of information than\n\u003e the blockchain.\n\u003e\n\nI think such synchronization won't be possible as we keep adding features,\nbecause the block chain cannot sync all the relevant data. For instance\nElectrum already has a label sync feature. Other wallets need to compete\nwith that, somehow, so we need to build a way to do cross-device wallet\nsync with non-chain data.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140327/41aaeab9/attachment.html\u003e"}