From: Mike Hearn <mike@plan99.net>
To: Jeff Garzik <jgarzik@exmulti.com>
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] New P2P commands for diagnostics, SPV clients
Date: Fri, 15 Jun 2012 13:52:56 +0200 [thread overview]
Message-ID: <CANEZrP0Tuzax2y9rjKmj12KP31ac96QaiuGYOxe2FnFBNu9jUA@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP0kNZDByHpK2=UjP+ag0X1KmqHxnJdm=e_pWMitP4QvvA@mail.gmail.com>
> Need to specify the format of how these arrive. It means that when a
> new block is found instead of inv<->getdata<->block we'd see something
> like inv<->getdata<->merkleblock where a "merkleblock" structure is a
> header + list of transactions + list of merkle branches linking them
> to the root.
Thinking about it some more and re-reading the Scalability wiki page,
I remembered that a nice bandwidth optimization to the protocol is to
distribute blocks as header+list of tx hashes. If a node has already
seen that tx before (eg, it's in the mempool) there is no need to send
it again.
With the new command to download the contents of the mempool on
startup, this means that blocks could potentially propagate across the
network faster as download time is taken out of the equation, and
indeed, with the signature cache the hard work of verifying is already
done. So this could also help reduce orphan blocks and spurious chain
splits.
Are you planning on implementing any of this Jeff? I think we have the
opportunity to kill a few birds with one or two stones.
next prev parent reply other threads:[~2012-06-15 11:53 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-13 20:46 [Bitcoin-development] New P2P commands for diagnostics, SPV clients Jeff Garzik
2012-06-14 11:52 ` Mike Hearn
2012-06-15 11:52 ` Mike Hearn [this message]
2012-06-15 13:19 ` Matt Corallo
2012-06-15 13:23 ` Mike Hearn
2012-06-15 14:39 ` Matt Corallo
2012-06-16 8:27 ` Mike Hearn
2012-06-19 19:09 ` Matt Corallo
2012-07-21 11:45 ` Mike Hearn
2012-07-23 7:54 ` Andreas Petersson
2012-07-23 16:40 ` Matt Corallo
2012-07-24 8:16 ` Mike Hearn
2012-06-15 13:26 ` Jeff Garzik
2012-06-15 13:43 ` Mike Hearn
2012-06-15 14:56 ` Matt Corallo
2012-06-15 15:32 ` Jeff Garzik
2012-06-15 16:20 ` Matt Corallo
2012-06-15 18:42 ` Amir Taaki
2012-06-16 8:25 ` Mike Hearn
2012-06-15 15:43 ` Simon Barber
2012-06-15 16:40 ` Jeff Garzik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CANEZrP0Tuzax2y9rjKmj12KP31ac96QaiuGYOxe2FnFBNu9jUA@mail.gmail.com \
--to=mike@plan99.net \
--cc=bitcoin-development@lists.sourceforge.net \
--cc=jgarzik@exmulti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox