Do you mean getdata? Here is the reason for the 6 new messages:
getseginv,seginv - These are for learning about what segments of a block a node
has. Else you could remove these messages and simply have nodes advertise
blocks via inventory messages. In this case nodes would have to wait until they
had fully received a block before relaying anything. No longer is there a
benefit with nodes being able to relay segments of blocks before they have
received the entire block.
gettreelevel,treelevel - These are to received a level of the merle tree.
Instead you might use get data but gettreelevel is more compact than get data
and is clearly differentiates itself as part of the new protocol. Perhaps these
messages could include the block headers alongside the hashes and you could
request many at once like with the getheaders message? If you skip these
messages, then you could verify the transactions at the end but there would be
problems when peers give bad segments where data would need to be downloaded
again.
getsegment,segment - These are clearly important to request and receive
segments for the blocks. These allows for nodes to download arbitrary segments
of blocks. The optimum number of segments could be calculated by node software
using measurements of download speeds and latency times, the number of
connections and how likely redundancy is to occur. If a node is up-to-date and
likely has many of the transactions in blocks, it can start asking for the
deepest merle level (tx hashes) and ask nodes for segments, avoiding
transactions it already has.
I'll get around to doing measurements myself sometime to estimate the benefit
of this proposal. It will certainly be beneficial when block sizes reach some
size but not much is really known except what can be assumed/guessed.
I should also mention the bitcointalk topic here:
https://bitcointalk.org/index.php?topic=103295.0
On 10 Sep 2012, at 19:59, "Luke-Jr" <l...@dashjr.org> wrote:
>
> Most of the problem with block propagation lies in implementation, not
> protocol... Distributing missing transaction on an as-needed basis is a
> possible improvement at the protocol level, but there hasn't (AFAIK) been any
> research into whether the little benefit outweighs the cost yet. In any case,
> I don't see why 6 new messages are needed instead of simply adding a single
> new type to getinv?
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
