{"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:2013-07-16\n📝 Original message:You'd want to create and get merged patches in the following order:\n\n1) Be able to store just block headers in the blkXXXX.dat files instead of\nfull block contents. At this point you are still *downloading* full blocks,\nbut they are not being stored. The contents are still sent to the wallet\nfor extracting relevant transactions though (see SyncWithWallets).  You\nalso need to disable listening and addr announcements to the P2P network at\nthis point. You need to be able to re-org and do all the usual things\nwithout storing block contents. You also need to short-circuit the leveldbs\nso they aren't created or used. All that needs to be unit tested. You need\nto also rewrite the mempool logic so it throws out irrelevant transactions.\nThe RPC interface needs to adjust itself so you can't try to start mining,\nquery the utxo set, etc.\n\nAt this point you have an SPV node, albeit one that still downloads the\nentire block chain. However total disk storage used will be much lower.\nGetting this written and reviewed is a big chunk of work but is the hardest\npart. Once it's done you can breath easy.\n\n2) Next step, use getheaders to catch up with the chain until the\nmin(wallet birthdays) is reached. You can see in Satoshi's patch where he\nadds support for receiving \"headers\" messages. Because key times are\nrecorded as dates and you don't know the dates of blocks in advance, you\nneed to download headers until you see one that goes past the key birthday\nminus some slack period, then throw out the headers you downloaded and\nswitch to downloading full blocks again from that point onwards.\n\n3) Next step, implement client side support for Bloom filtering. Switch\nfrom downloading full blocks to filteredblocks, verify the Merkle branches\nthen apply them to the wallet. Watch out for accidental re-orderings of\ntransactions here from block order (e.g. if you accidentally insert them\ninto a std::map or other unordered collection it can lead to bugs). Come up\nwith some way to decide on a FP rate. Probably you want a fairly high FP\nrate for desktop wallets.\n\n4) Next step (optional), implement monitoring of broadcast propagation for\ntransactions that are received. SPV clients cannot verify unconfirmed\ntransactions so you can either just give up entirely and accept any old\ngarbage, or assume a non-MITMd internet connection and use network\npropagation as a rough proxy for \"likely to be valid and mined upon\".\n\n4) Optimize!\n\nHow much you need to optimize really depends on a lot of things. I found\nthat to be competitive with Electrum/blockchain.info I had to do a ton of\noptimizations including very aggressive checkpointing so new users don't\nhave to download more than a month or twos worth of headers, as downloading\nall the headers was becoming a bottleneck. You'd need to download about\n16mb+ of data at the moment to grab all the headers and on a weakass mobile\nphone with a weak Dalvik VM and 3G internet this was way too much. I also\nhad to spend some time profiling to ensure we weren't accidentally\nthrashing the UI due to too-fast updates, we weren't bottlenecking on\nupdating last seen block data in the wallet, we weren't accidentally\nde/reserializing messages redundantly etc.\n\nAfter about 3-4 evenings of non-stop profiling and optimising I ended up\nwith a relatively flat profile whilst doing initial catchup and chain sync.\nOn a desktop I bet you can get away with much less optimisation because\nyour CPUs, network and disk tend to be much stronger.\n\n\n\nOn Tue, Jul 16, 2013 at 4:16 PM, Wendell \u003cw at grabhive.com\u003e wrote:\n\n\u003e Hello everyone,\n\u003e\n\u003e In the previous thread, I expressed interest in seeing an SPV bitcoind,\n\u003e further stating that I would fund such work. Mike Hearn followed up with\n\u003e some of Satoshi's old code for this, which is now quite broken. The offer\n\u003e and interest on my side still stand, as more diversity in SPV options seems\n\u003e like the right way to go.\n\u003e\n\u003e Time-permitting, I would really appreciate feedback from knowledgable\n\u003e parties about the possible approaches to an SPV bitcoind. We at Hive\n\u003e ideally want to see something that could one be merge into master, rather\n\u003e than a fork.\n\u003e\n\u003e -wendell\n\u003e\n\u003e grabhive.com | twitter.com/grabhive\n\u003e\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e See everything from the browser to the database with AppDynamics\n\u003e Get end-to-end visibility with application monitoring from AppDynamics\n\u003e Isolate bottlenecks and diagnose root cause in seconds.\n\u003e Start your free trial of AppDynamics Pro today!\n\u003e http://pubads.g.doubleclick.net/gampad/clk?id=48808831\u0026iu=/4140/ostg.clktrk\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130716/0e2c8341/attachment.html\u003e"}