📅 Original date posted:2016-05-11
📝 Original message:Ups, I forgot that you take the midstate which of course depends on the
version number. So forget everything I said about the version bits. You are
right. But why take the midstate? It can be any hash of the first chunk. So
you probably want to take a hash function that's available in standard
software libraries. And I suppose midstate() is not.
On Wed, May 11, 2016 at 11:28 AM, Timo Hanke <timo.hanke at web.de> wrote:
> Sorry, you must have meant all 12 bytes. That makes finding a collision
> substantially harder. However, you may have to restrict yourself to 10
> bytes because you don't know if any hardware does timestamp rolling
> on-chip. Also you create an incentive to mess around with the version bits
> instead, so you would have to fix that as well. So it basically means a new
> mining header with the real blockheader as a child header.
>
> On Wed, May 11, 2016 at 9:24 AM, Timo Hanke <timo.hanke at web.de> wrote:
>
>> 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/faae91b2/attachment.html>;
Timo Hanke [ARCHIVE] /
npub1dd…pgp9a
2023-06-07 17:50:32
in reply to nevent1q…n6j2
Author Public Key
npub1ddqaln8xsfmy6sxqplt9sz5ev99kh052sveqsh02q7hmc3a6n68shpgp9aSeen on
wss://relay.nostr.bandPublished at
2023-06-07 17:50:32Event JSON
{
"id": "2b97ebd7cf5640ee59353d30eed31c51583d0f14ecbf5908c8934ce1e0cfe156",
"pubkey": "6b41dfcce682764d40c00fd6580a99614b6bbe8a8332085dea07afbc47ba9e8f",
"created_at": 1686160232,
"kind": 1,
"tags": [
[
"e",
"b74d6e3e945ee090c612026984f249efe6d61ca521fddbb0329fa69f81265a0b",
"",
"root"
],
[
"e",
"468e14ee5847e36cb0d6e6b3a932bfd385f415ee60277e36194da2c66e822982",
"",
"reply"
],
[
"p",
"6b41dfcce682764d40c00fd6580a99614b6bbe8a8332085dea07afbc47ba9e8f"
]
],
"content": "📅 Original date posted:2016-05-11\n📝 Original message:Ups, I forgot that you take the midstate which of course depends on the\nversion number. So forget everything I said about the version bits. You are\nright. But why take the midstate? It can be any hash of the first chunk. So\nyou probably want to take a hash function that's available in standard\nsoftware libraries. And I suppose midstate() is not.\n\n\nOn Wed, May 11, 2016 at 11:28 AM, Timo Hanke \u003ctimo.hanke at web.de\u003e wrote:\n\n\u003e Sorry, you must have meant all 12 bytes. That makes finding a collision\n\u003e substantially harder. However, you may have to restrict yourself to 10\n\u003e bytes because you don't know if any hardware does timestamp rolling\n\u003e on-chip. Also you create an incentive to mess around with the version bits\n\u003e instead, so you would have to fix that as well. So it basically means a new\n\u003e mining header with the real blockheader as a child header.\n\u003e\n\u003e On Wed, May 11, 2016 at 9:24 AM, Timo Hanke \u003ctimo.hanke at web.de\u003e wrote:\n\u003e\n\u003e\u003e Luke, do you mean to replace the first 4 bytes of the second chunk (bytes\n\u003e\u003e 64..67 in 0-based counting) by the XOR of those 4 bytes with the first 4\n\u003e\u003e bytes of the midstate? (I assume you don't care about 12 bytes but rather\n\u003e\u003e those 4 bytes.)\n\u003e\u003e\n\u003e\u003e This does not work. All it does is adding another computational step\n\u003e\u003e before you can check for a collision in those 4 bytes. It makes finding a\n\u003e\u003e collision only marginally harder.\n\u003e\u003e\n\u003e\u003e On Wed, May 11, 2016 at 7:28 AM, Luke Dashjr via bitcoin-dev \u003c\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e On Wednesday, May 11, 2016 12:20:55 PM Sergio Demian Lerner via\n\u003e\u003e\u003e bitcoin-dev\n\u003e\u003e\u003e wrote:\n\u003e\u003e\u003e \u003e On Tue, May 10, 2016 at 6:43 PM, Sergio Demian Lerner \u003c\n\u003e\u003e\u003e \u003e sergio.d.lerner at gmail.com\u003e wrote:\n\u003e\u003e\u003e \u003e \u003e You can find it here:\n\u003e\u003e\u003e \u003e \u003e\n\u003e\u003e\u003e https://bitslog.wordpress.com/2014/03/18/the-re-design-of-the-bitcoin-blo\n\u003e\u003e\u003e \u003e \u003e ck-header/\n\u003e\u003e\u003e \u003e \u003e\n\u003e\u003e\u003e \u003e \u003e Basically, the idea is to put in the first 64 bytes a 4 byte hash of\n\u003e\u003e\u003e the\n\u003e\u003e\u003e \u003e \u003e second 64-byte chunk. That design also allows increased nonce space\n\u003e\u003e\u003e in\n\u003e\u003e\u003e \u003e \u003e the first 64 bytes.\n\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e \u003e My mistake here. I didn't recalled correctly my own idea. The idea is\n\u003e\u003e\u003e to\n\u003e\u003e\u003e \u003e include in the second 64-byte chunk a 4-byte hash of the first chunk,\n\u003e\u003e\u003e not\n\u003e\u003e\u003e \u003e the opposite.\n\u003e\u003e\u003e\n\u003e\u003e\u003e What if we XOR bytes 64..76 with the first 12 bytes of the SHA2 midstate?\n\u003e\u003e\u003e Would that work?\n\u003e\u003e\u003e\n\u003e\u003e\u003e Luke\n\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160511/faae91b2/attachment.html\u003e",
"sig": "277a7b835f38d11faf01b00c3f3b7c24d2a4a0e5bb44c8126bba555e0abf5f1cb171774fcabf4e9190501dbf295970883d324e453c6c965d7a02fb440354949e"
}