{"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-04-10\n📝 Original message:\u003e\n\u003e What would this involve?\n\u003e\n\u003e Do you know of any previous work towards this?\n\u003e\n\nChain pruning is a fairly complicated project, partly because it spans\ncodebases. For instance if you try and implement it *just* by changing\nBitcoin Core, you will break all the SPV clients based on bitcoinj (i.e.\nall of them). Big changes to the P2P network like this require upgrading\nboth codebases simultaneously.\n\nI think things like this may be why Gavin is now just \"chief scientist\"\ninstead of Core maintainer - in future, the changes people need will span\nprojects and require fairly significant planning.\n\n\u003eFrom a technical perspective, it means extending addr broadcasts so nodes\nbroadcast how much of the chain they have, and teaching both Core and\nbitcoinj how to search for nodes that have enough of the chain for them to\nuse. Currently bitcoinj still doesn't use addr broadcasts at all, there's\nan incomplete patch available but it was never finished or merged. So that\nhas to be fixed first. And that probably implies improving Bitcoin Core so\nthe results of getaddr are more usable, ideally as high quality as what the\nDNS seeds provide, because if lots of bad addresses are returned this will\nslow down initial connect time, which is an important performance metric.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140410/3beeb426/attachment.html\u003e"}