{"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:2016-05-08\n📝 Original message:(This response was originally off-list as moderators were still\ndeciding, here it is for those interested).\n\nHi Tom,\n\nThanks for reading the draft text and commenting! Replies inline.\n\nMatt\n\nOn 05/08/16 00:40, Johnathan Corgan wrote:\n\u003e ---------- Forwarded message ----------\n\u003e From: Tom \u003ctomz at freedommail.ch \u003cmailto:tomz at freedommail.ch\u003e\u003e\n\u003e To: bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e, Matt Corallo \u003clf-lists at mattcorallo.com \u003cmailto:lf-lists at mattcorallo.com\u003e\u003e\n\u003e Cc: \n\u003e Date: Fri, 06 May 2016 13:31:15 +0100\n\u003e Subject: Re: [bitcoin-dev] Compact Block Relay BIP\n\u003e On Monday 02 May 2016 22:13:22 Matt Corallo via bitcoin-dev wrote:\n\u003e \n\u003e Thanks for putting in the time to make a spec!\n\u003e \n\u003e It looks good already, but I do think some more improvements can be made.\n\u003e \n\u003e \n\u003e\u003e ===Intended Protocol Flow===\n\u003e I'm not a fan of the solution that a CNode should keep state and talk to\n\u003e its remote nodes differently while announcing new blocks.\n\u003e Its too complicated and ultimately counter-productive.\n\u003e \n\u003e The problem is that an individual node needs to predict network behaviour in\n\u003e advance. With the downside that if it guesses wrong that both nodes end up\n\u003e paying for the wrong guess.\n\u003e This is not a good way to design a p2p layer.\n\nNodes don't need to predict much in advance, and the cost for predicting\nwrong is 0 if your peers receive blocks with a few hundred ms between\nthem (as we should expect) and you haven't set the announce bit on more\nthan a few peers (as the spec requires for this reason). As for\ncomplexity of keeping state, think of it as a version flag in much the\nsame way sendheaders operates.\n\nIt seems I forgot to add a suggested peer-preforwarding-selection\nalgorithm in the text, but the intended use-case is to set the bit on\npeers which recently provided you blocks faster than other peers, up to\nonly one or three peers. This is both simple and should be incredibly\neffective.\n\n[This has now been clarified in the BIP text]\n\n\u003e I would suggest that a new block is announced to all nodes equally and then\n\u003e individual nodes can respond with a request of either a 'compact' or a\n\u003e normal block.\n\u003e This is much more in line with the current design as well.\n\u003e \n\u003e Detection if remote nodes support compact blocks, for the purpose of\n\u003e requesting a compact-block, can be done either via a network-bit or just a\n\u003e protocol version. Or something else entirely, if you have better\n\u003e suggestions.\n\nIn line with recent trends, neither service bits nor protocol versions\nare particularly well-suited for this purpose. Protocol versions are\nimpossible to handle sanely across different nodes on the network, as\nthey cannot indicate optional features. Service bits, while somewhat\nmore appropriate for this purpose, are a very limited resource which is\ngenerally better suited to indicating significant new features which\nnodes might need for correct operation, and thus might wish to actively\nseek out when making connections. I'm not sure anyone is suggesting that\nhere, and absent that recent agreement preferred message-based feature\nindication instead of version-message-extension.\n\n\u003e\u003e Variable-length integers: bytes are a MSB base-128 encoding of the\n\u003e\u003e number.\n\u003e\u003e The high bit in each byte signifies whether another digit follows.\n\u003e\u003e [snip bitwise spec]\n\u003e \n\u003e I suggest just referring to UTF-8 which describes this just fine.\n\u003e it is good practice to refer to existing specs when possible and not copy\n\u003e the details.\n\nHmm? There is no UTF anywhere in this protocol. Indeed this section\nneeds to be rewritten, as indicated. I'd recommend you read the code\nuntil I update the section with better text if you're confused.\n\n\u003e\u003e ====Short transaction IDs====\n\u003e\u003e Short transaction IDs are used to represent a transaction without\n\u003e\u003e sending a full 256-bit hash. They are calculated by:\n\u003e\u003e # single-SHA256 hashing the block header with the nonce appended (in\n\u003e\u003e little-endian)\n\u003e\u003e # XORing each 8-byte chunk of the double-SHA256 transaction hash with\n\u003e\u003e each corresponding 8-byte chunk of the hash from the previous step\n\u003e\u003e # Adding each of the XORed 8-byte chunks together (in little-endian)\n\u003e\u003e iteratively to find the short transaction ID\n\u003e \n\u003e I don't think this is needed. Just use the first 8 bytes.\n\u003e The reason to do xor-ing doesn't hold up and extra complexity is unneeded.\n\u003e Especially since you mention some lines down;\n\u003e \n\u003e\u003e The short transaction ID calculation is designed to take absolutely\n\u003e\u003e minimal processing time during block compaction to avoid introducing\n\u003e\u003e serious DoS vulnerabilities\n\nI'm confused as to what, specifically, you're proposing this be changed\nto. I'm pretty sure the proposed protocol is about as simple as you can\nget while retaining some reasonable collision resistance. I might,\nhowever, decide to switch to siphash with a very low round count, given\nthat it's probably faster than the cache-fill-time taken by just\niterating over the mempool. Needs a bit further investigation.\n\n\u003e ==Acknowledgements==\n\u003e \n\u003e I think you need to acknowledge some more people, or just remove this\n\u003e paragraph.\n\u003e \n\u003e Cheers\n\nGreg was the only large contributor to the document (and was a very\nlarge contributor, as mentioned - the work is based hugely on a protocol\nrecommendation he wrote up several years ago) don't see why this should\nmean he doesn't get credit.\n\n[For those interested, I'm referring here to\nhttps://en.bitcoin.it/wiki/User:Gmaxwell/block_network_coding. This\nBIP/the implementation is a precursor to an implementation that looks\nsimilar to what Greg proposes there which can be found on my udp-wip\nbranch, which is based on and uses the data structures involved here.]"}