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@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@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@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@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev