{"type":"rich","version":"1.0","author_name":"npub1h394c0pkdum0jw4rufslt3ur9m9c2ym4x7a0t68spfpjr6zlq3msu8z4k5","author_url":"https://nostr.ae/npub1h394c0pkdum0jw4rufslt3ur9m9c2ym4x7a0t68spfpjr6zlq3msu8z4k5","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2016-05-09\n📝 Original message:On Monday 09 May 2016 10:43:02 Gregory Maxwell wrote:\n\u003e On Mon, May 9, 2016 at 9:35 AM, Tom Zander via bitcoin-dev\n\u003e \n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e You misunderstand the networking effects.\n\u003e \u003e The fact that your node is required to choose which one to set the\n\u003e \u003e announce\n\u003e \u003e bit on implies that it needs to predict which node will have the best data\n\u003e \u003e in the future.\n\u003e \n\u003e Not required. It may. \n\nIt is required, in the reference of wanting to actually use compact block \nrelay.\n\n\n\u003e Testing on actual nodes in the actual network (not a \"lab\") shows\n\nApologies, I thought that the term was wider known.  \"Laboratory situations\" \nis used where I am from as the opposite of real-world messy and unpredictable \nsituations.\n\nSo, your measurements may be true, but are not useful to decide how well it \nbehaves under less optimal situations. aka \"the real world\".\n\n\u003e This also _increases_ robustness. Right now a single peer failing at\n\u003e the wrong time will delay blocks with a long time out.\n\nIf your peers that were supposed to send you a compact block fail, then you'll \nend up in exactly that same situation again.  Only with various timeouts in \nbetween before you get your block making it a magnitude slower.\n\nIn networking this is solved by reacting instead of predicting. The network is \nnot stable. Your protocol design assumes it to be.\n\n\n\u003e \u003e Another problem with your solution is that nodes send a much larger amount\n\u003e \u003e of unsolicited data to peers in the form of the thin-block compared to\n\u003e \u003e the normal inv or header-first data.\n\u003e \n\u003e \"High bandwidth\" mode \n\nAnother place where I may have explained better.\nThis is not about the difference about the two modes of your design.\nThis is about the design as a whole. As compared to current.\n\n\n\u003e \u003e Am I to understand that you choose the solution based on the fact that\n\u003e \u003e service bits are too expensive to extend? (if not, please respond to my\n\u003e \u003e previous question actually answering the suggestion)\n\u003e \u003e \n\u003e \u003e That sounds like a rather bad way of doing design. Maybe you can add a\n\u003e \u003e second service bits field of message instead and then do the compact\n\u003e \u003e blocks correctly.\n\u003e Service bits are not generally a good mechanism for negating optional\n\u003e peer-local parameters.\n\nService bits are exactly the right solution to indicate additional p2p \nfeature-support.\n\n\n\u003e [It's a little disconcerting that you appear to be maintaining a fork\n\u003e and are unaware of this.]\n\nehm...\n\n\n\u003e \u003e Wait, you didn't steal the variable length encoding from an existing\n\u003e \u003e standard and you programmed a new one?\n\u003e \n\u003e This is one of the two variable length encodings used for years in\n\u003e Bitcoin Core. This is just the first time it's shown up in a BIP.\n\u003e\n\u003e \u003e Look at UTF-8 on wikipedia, you may have \"invented\" the same encoding that\n\u003e \u003e IBM published in 1992.\n\u003e \n\u003e The similarity with UTF-8 is that both are variable length and some\n\u003e control information is in the high bits. The similarity ends there.\n\nThat's all fine and well, it doesn't at any point take away from my point that \nany specification should NOT invent something new that has for decades had a \ngreat specification already.\n\nIf you make a spec to be used by all nodes, on the wire, don't base it on your \nproprietary implementation. Please.\n\n\n\u003e \u003e Just the first (highest) 8 bytes of a sha256 hash.\n\u003e \u003e \n\u003e \u003e The amount of collisions will not be less if you start xoring the rest.\n\u003e \u003e The whole reason for doing this extra work is also irrelevant as a spam\n\u003e \u003e protection.\n\u003e \n\u003e Then you expose it to a trivial collision attack:  To find two 64 bit\n\u003e hashes that collide I need perform only roughly 2^32 computation. Then\n\u003e I can send them to the network.\n\nNo, you still need to have done a POW.\n\nNext to that, your scheme is 2^32 computations *and* some XORs. The XORs are \npercentage wise a rounding error on the total time. So your argument also \ndestroys your own addition.\n\n\u003e This issue is eliminated by salting the hash. \n\nThe issue is better eliminated by not allowing nodes to send uninvited large \nmessages.\n\nI don't think we're getting anywhere.\n\nI'm not sold on your design and I explained why. I tried explaining in this \nemail some misconceptions that may have appeared after my initial emails. I \nhope things are more clear."}