rich1.0npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcuhttps://nostr.ae/npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcunjumphttps://nostr.ae📅 Original date posted:2012-09-10 📝 Original message:I actually implemented parts of the header+ v<tx> stuff in a branch with my bloom filter stuff, you can see it here: https://github.com/TheBlueMatt/bitcoin/commits/bloom%2Brelayblock Its pretty stupid and would be pretty easy to DoS/get it stuck/etc, but in theory it works. I don't see much reason why we'd need anything significantly more complicated, but maybe there is a use-case I'm missing? Matt On Mon, 2012-09-10 at 11:14 -0400, Gregory Maxwell wrote: > On Mon, Sep 10, 2012 at 11:07 AM, Matthew Mitchell > <matthewmitchell at godofgod.co.uk> wrote: > > Here is a BIP draft for improving the block relaying and validation so that > > it can be done in parallel and so that redundancy can be removed. This > > becomes more beneficial the larger the block sizes are. > > > > https://en.bitcoin.it/wiki/User:MatthewLM/ImprovedBlockRelayingProposal > > Why does this focus on actually sending the hash tree? The block > header + transaction list + transactions a node doesn't already know > (often just the coinbase) is enough.