📅 Original date posted:2016-05-11
📝 Original message:Luke, do you mean to replace the first 4 bytes of the second chunk (bytes
64..67 in 0-based counting) by the XOR of those 4 bytes with the first 4
bytes of the midstate? (I assume you don't care about 12 bytes but rather
those 4 bytes.)
This does not work. All it does is adding another computational step before
you can check for a collision in those 4 bytes. It makes finding a
collision only marginally harder.
On Wed, May 11, 2016 at 7:28 AM, Luke Dashjr via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Wednesday, May 11, 2016 12:20:55 PM Sergio Demian Lerner via bitcoin-dev
> wrote:
> > On Tue, May 10, 2016 at 6:43 PM, Sergio Demian Lerner <
> > sergio.d.lerner at gmail.com> wrote:
> > > You can find it here:
> > >
> https://bitslog.wordpress.com/2014/03/18/the-re-design-of-the-bitcoin-blo
> > > ck-header/
> > >
> > > Basically, the idea is to put in the first 64 bytes a 4 byte hash of
> the
> > > second 64-byte chunk. That design also allows increased nonce space in
> > > the first 64 bytes.
> >
> > My mistake here. I didn't recalled correctly my own idea. The idea is to
> > include in the second 64-byte chunk a 4-byte hash of the first chunk, not
> > the opposite.
>
> What if we XOR bytes 64..76 with the first 12 bytes of the SHA2 midstate?
> Would that work?
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160511/499e1347/attachment.html>;
Timo Hanke [ARCHIVE] /
npub1dd…pgp9a
2023-06-07 17:50:32
in reply to nevent1q…uf5a
Author Public Key
npub1ddqaln8xsfmy6sxqplt9sz5ev99kh052sveqsh02q7hmc3a6n68shpgp9aPublished at
2023-06-07 17:50:32Event JSON
{
"id": "0c0ca42bb6bec5cceb7ab8979d61cfc6e01e854ef601ec38e23e25f6f9e7df3e",
"pubkey": "6b41dfcce682764d40c00fd6580a99614b6bbe8a8332085dea07afbc47ba9e8f",
"created_at": 1686160232,
"kind": 1,
"tags": [
[
"e",
"b74d6e3e945ee090c612026984f249efe6d61ca521fddbb0329fa69f81265a0b",
"",
"root"
],
[
"e",
"56136f902cbb4720de0b1b69bd73ffafd08e638f8a190d7eb682d219fa505c21",
"",
"reply"
],
[
"p",
"5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803"
]
],
"content": "📅 Original date posted:2016-05-11\n📝 Original message:Luke, do you mean to replace the first 4 bytes of the second chunk (bytes\n64..67 in 0-based counting) by the XOR of those 4 bytes with the first 4\nbytes of the midstate? (I assume you don't care about 12 bytes but rather\nthose 4 bytes.)\n\nThis does not work. All it does is adding another computational step before\nyou can check for a collision in those 4 bytes. It makes finding a\ncollision only marginally harder.\n\nOn Wed, May 11, 2016 at 7:28 AM, Luke Dashjr via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On Wednesday, May 11, 2016 12:20:55 PM Sergio Demian Lerner via bitcoin-dev\n\u003e wrote:\n\u003e \u003e On Tue, May 10, 2016 at 6:43 PM, Sergio Demian Lerner \u003c\n\u003e \u003e sergio.d.lerner at gmail.com\u003e wrote:\n\u003e \u003e \u003e You can find it here:\n\u003e \u003e \u003e\n\u003e https://bitslog.wordpress.com/2014/03/18/the-re-design-of-the-bitcoin-blo\n\u003e \u003e \u003e ck-header/\n\u003e \u003e \u003e\n\u003e \u003e \u003e Basically, the idea is to put in the first 64 bytes a 4 byte hash of\n\u003e the\n\u003e \u003e \u003e second 64-byte chunk. That design also allows increased nonce space in\n\u003e \u003e \u003e the first 64 bytes.\n\u003e \u003e\n\u003e \u003e My mistake here. I didn't recalled correctly my own idea. The idea is to\n\u003e \u003e include in the second 64-byte chunk a 4-byte hash of the first chunk, not\n\u003e \u003e the opposite.\n\u003e\n\u003e What if we XOR bytes 64..76 with the first 12 bytes of the SHA2 midstate?\n\u003e Would that work?\n\u003e\n\u003e Luke\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160511/499e1347/attachment.html\u003e",
"sig": "5a308d46df00f28d0f05b2febcf064f566917802d16d2feb68c5c481b706431bcf8891cb902895896df3c0cbcea68812821075e31f93da284a5959061bb30b89"
}