[bitcoin-dev] Making AsicBoost irrelevant
timo.hanke at web.de
Wed May 11 22:49:25 UTC 2016
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
>>> > On Tue, May 10, 2016 at 6:43 PM, Sergio Demian Lerner <
>>> > sergio.d.lerner at gmail.com> wrote:
>>> > > You can find it here:
>>> > >
>>> > > ck-header/
>>> > >
>>> > > Basically, the idea is to put in the first 64 bytes a 4 byte hash of
>>> > > second 64-byte chunk. That design also allows increased nonce space
>>> > > the first 64 bytes.
>>> > My mistake here. I didn't recalled correctly my own idea. The idea is
>>> > include in the second 64-byte chunk a 4-byte hash of the first chunk,
>>> > the opposite.
>>> What if we XOR bytes 64..76 with the first 12 bytes of the SHA2 midstate?
>>> Would that work?
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bitcoin-dev