{"type":"rich","version":"1.0","author_name":"npub1ddqaln8xsfmy6sxqplt9sz5ev99kh052sveqsh02q7hmc3a6n68shpgp9a","author_url":"https://nostr.ae/npub1ddqaln8xsfmy6sxqplt9sz5ev99kh052sveqsh02q7hmc3a6n68shpgp9a","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2016-05-11\n📝 Original message:Sorry, you must have meant all 12 bytes. That makes finding a collision\nsubstantially harder. However, you may have to restrict yourself to 10\nbytes because you don't know if any hardware does timestamp rolling\non-chip. Also you create an incentive to mess around with the version bits\ninstead, so you would have to fix that as well. So it basically means a new\nmining header with the real blockheader as a child header.\n\nOn Wed, May 11, 2016 at 9:24 AM, Timo Hanke \u003ctimo.hanke at web.de\u003e wrote:\n\n\u003e Luke, do you mean to replace the first 4 bytes of the second chunk (bytes\n\u003e 64..67 in 0-based counting) by the XOR of those 4 bytes with the first 4\n\u003e bytes of the midstate? (I assume you don't care about 12 bytes but rather\n\u003e those 4 bytes.)\n\u003e\n\u003e This does not work. All it does is adding another computational step\n\u003e before you can check for a collision in those 4 bytes. It makes finding a\n\u003e collision only marginally harder.\n\u003e\n\u003e On Wed, May 11, 2016 at 7:28 AM, Luke Dashjr via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e On Wednesday, May 11, 2016 12:20:55 PM Sergio Demian Lerner via\n\u003e\u003e bitcoin-dev\n\u003e\u003e wrote:\n\u003e\u003e \u003e On Tue, May 10, 2016 at 6:43 PM, Sergio Demian Lerner \u003c\n\u003e\u003e \u003e sergio.d.lerner at gmail.com\u003e wrote:\n\u003e\u003e \u003e \u003e You can find it here:\n\u003e\u003e \u003e \u003e\n\u003e\u003e https://bitslog.wordpress.com/2014/03/18/the-re-design-of-the-bitcoin-blo\n\u003e\u003e \u003e \u003e ck-header/\n\u003e\u003e \u003e \u003e\n\u003e\u003e \u003e \u003e Basically, the idea is to put in the first 64 bytes a 4 byte hash of\n\u003e\u003e the\n\u003e\u003e \u003e \u003e second 64-byte chunk. That design also allows increased nonce space in\n\u003e\u003e \u003e \u003e the first 64 bytes.\n\u003e\u003e \u003e\n\u003e\u003e \u003e My mistake here. I didn't recalled correctly my own idea. The idea is to\n\u003e\u003e \u003e include in the second 64-byte chunk a 4-byte hash of the first chunk,\n\u003e\u003e not\n\u003e\u003e \u003e the opposite.\n\u003e\u003e\n\u003e\u003e What if we XOR bytes 64..76 with the first 12 bytes of the SHA2 midstate?\n\u003e\u003e Would that work?\n\u003e\u003e\n\u003e\u003e Luke\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160511/6cb58d22/attachment.html\u003e"}