{"type":"rich","version":"1.0","author_name":"npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcu","author_url":"https://nostr.ae/npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcu","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2012-09-10\n📝 Original message:It seems to me the whole idea of segmenting blocks would add very little\n(to nothing) with any sane block size.  Sure, if a block were to be\n10GB, it may make sense.  However, even in that case, it would be easier\nto relay a list of tx hashes (which may be a bit expensive) and txes\nseparately instead of using a notion of block segments.  That said, I\ndon't see blocks ever being that large and if they do become that large,\nas only a few full nodes will remain, upgrading their protocol would be\n(relatively) easy.  I would instead encourage focus on decreasing block\nrelay times for the current network and as blocks approach 10MB (so that\nthey can approach 10MB).\n\nMatt\n\nOn Mon, 2012-09-10 at 20:34 +0100, Matthew Mitchell wrote:\n\u003e Do you mean getdata? Here is the reason for the 6 new messages:\n\u003e \n\u003e \n\u003e getseginv,seginv - These are for learning about what segments of a\n\u003e block a node has. Else you could remove these messages and simply have\n\u003e nodes advertise blocks via inventory messages. In this case nodes\n\u003e would have to wait until they had fully received a block before\n\u003e relaying anything. No longer is there a benefit with nodes being able\n\u003e to relay segments of blocks before they have received the entire\n\u003e block.\n\u003e \n\u003e \n\u003e gettreelevel,treelevel - These are to received a level of\n\u003e the merle tree. Instead you might use get data but gettreelevel is\n\u003e more compact than get data and is clearly differentiates itself as\n\u003e part of the new protocol. Perhaps these messages could include the\n\u003e block headers alongside the hashes and you could request many at once\n\u003e like with the getheaders message? If you skip these messages, then you\n\u003e could verify the transactions at the end but there would be problems\n\u003e when peers give bad segments where data would need to be downloaded\n\u003e again.\n\u003e \n\u003e \n\u003e getsegment,segment - These are clearly important to request and\n\u003e receive segments for the blocks. These allows for nodes\n\u003e to download arbitrary segments of blocks. The optimum number of\n\u003e segments could be calculated by node software using measurements of\n\u003e download speeds and latency times, the number of connections and how\n\u003e likely redundancy is to occur. If a node is up-to-date and likely has\n\u003e many of the transactions in blocks, it can start asking for the\n\u003e deepest merle level (tx hashes) and ask nodes for segments, avoiding\n\u003e transactions it already has.\n\u003e \n\u003e \n\u003e I'll get around to doing measurements myself sometime to estimate the\n\u003e benefit of this proposal. It will certainly be beneficial when block\n\u003e sizes reach some size but not much is really known except what can be\n\u003e assumed/guessed.\n\u003e \n\u003e \n\u003e I should also mention the bitcointalk topic\n\u003e here: https://bitcointalk.org/index.php?topic=103295.0\n\u003e \n\u003e On 10 Sep 2012, at 19:59, \"Luke-Jr\" \u003cluke at dashjr.org\u003e wrote:\n\u003e \u003e \n\u003e \u003e Most of the problem with block propagation lies in implementation,\n\u003e \u003e not \n\u003e \u003e protocol... Distributing missing transaction on an as-needed basis\n\u003e \u003e is a \n\u003e \u003e possible improvement at the protocol level, but there hasn't (AFAIK)\n\u003e \u003e been any \n\u003e \u003e research into whether the little benefit outweighs the cost yet. In\n\u003e \u003e any case, \n\u003e \u003e I don't see why 6 new messages are needed instead of simply adding a\n\u003e \u003e single \n\u003e \u003e new type to getinv?"}