<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Do you mean getdata? Here is the reason for the 6 new messages:</div><div><br></div><div><span style="font-family: sans-serif; font-size: 13px; line-height: 19.200000762939453px; background-color: rgb(255, 255, 255); ">getseginv,</span><span style="font-family: sans-serif; font-size: 13px; line-height: 19.200000762939453px; background-color: rgb(255, 255, 255); ">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 </span><font face="sans-serif"><span style="font-size: 13px; line-height: 19px;">relay segments of blocks before they have received the entire block.</span></font></div><div><font face="sans-serif"><span style="font-size: 13px; line-height: 19px;"><br></span></font></div><div><span style="font-family: sans-serif; font-size: 13px; line-height: 19.200000762939453px; background-color: rgb(255, 255, 255); ">gettreelevel,</span><span style="background-color: rgb(255, 255, 255); "><font face="sans-serif"><span style="font-size: 13px; line-height: 19.200000762939453px;">treelevel - These are to received a level of the </span><span style="font-size: 13px; line-height: 19px;">merle</span><span style="font-size: 13px; line-height: 19.200000762939453px;"> tree. Instead you might use </span><span style="font-size: 13px; line-height: 19px;">get data</span><span style="font-size: 13px; line-height: 19.200000762939453px;"> but gettreelevel is more compact than </span><span style="font-size: 13px; line-height: 19px;">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.</span></font></span></div><div><span style="background-color: rgb(255, 255, 255); "><font face="sans-serif"><span style="font-size: 13px; line-height: 19px;"><br></span></font></span></div><div><span style="font-family: sans-serif; font-size: 13px; line-height: 19.200000762939453px; background-color: rgb(255, 255, 255); ">getsegment,</span><span style="background-color: rgb(255, 255, 255); "><font face="sans-serif"><span style="font-size: 13px; line-height: 19.200000762939453px;">segment - These are clearly important to request and receive segments for the blocks. These </span><span style="font-size: 13px; line-height: 19px;">allows for nodes to download arbitrary segments of blocks</span><span style="font-size: 13px; line-height: 19.200000762939453px;">. The optimum number of segments could be calculated by node software using </span><span style="font-size: 13px; line-height: 19px;">measurements</span><span style="font-size: 13px; line-height: 19.200000762939453px;"> 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 </span></font></span><font face="sans-serif"><span style="font-size: 13px; line-height: 19px;">merle level (tx hashes) and ask nodes for segments, avoiding transactions it already has.</span></font></div><div><span style="background-color: rgb(255, 255, 255); "><font face="sans-serif"><span style="font-size: 13px; line-height: 19.200000762939453px;"><br></span></font></span></div><div><span style="background-color: rgb(255, 255, 255); "><font face="sans-serif"><span style="font-size: 13px; line-height: 19.200000762939453px;">I'll get around to doing </span><span style="font-size: 13px; line-height: 19px;">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.</span></font></span></div><div><span style="background-color: rgb(255, 255, 255); "><font face="sans-serif"><span style="font-size: 13px; line-height: 19px;"><br></span></font></span></div><div><span style="background-color: rgb(255, 255, 255); "><font face="sans-serif"><span style="font-size: 13px; line-height: 19px;">I should also mention the bitcointalk topic here: </span></font></span><a href="https://bitcointalk.org/index.php?topic=103295.0">https://bitcointalk.org/index.php?topic=103295.0</a></div><br><div><div>On 10 Sep 2012, at 19:59, "Luke-Jr" <<a href="mailto:luke@dashjr.org">luke@dashjr.org</a>> wrote:</div><blockquote type="cite"><br>Most of the problem with block propagation lies in implementation, not <br>protocol... Distributing missing transaction on an as-needed basis is a <br>possible improvement at the protocol level, but there hasn't (AFAIK) been any <br>research into whether the little benefit outweighs the cost yet. In any case, <br>I don't see why 6 new messages are needed instead of simply adding a single <br>new type to getinv?<br></blockquote></div><br></body></html>