That'd be 7 bytes of nonce in the block header, which is
72,057,594,037,927,936 ~ 72 petahashes = 72,000 terahashes
So: the changes for version 2 blocks would be has height in the
coinbase, and has a 1-byte version number with a 3-byte extranonce.
I don't understand why more nonce bits
My point is that stuffing nonces into whatever spaces we can find to
eke out a bit more scalability in pools seems like a very short term
fix with potentially very long term consequences.
Although it may sound harsh, if your pool is struggling to keep up
with calculating merkle roots (which is
Hi Steve,
45-90 minutes - note that its numbers from March/April, so a bit longer today,
but far, far away from the 12 hours.
I am using libcoin and the bitcoind build based on this. Libcoin is based on
the Satoshi client, but refactured to use an async concurrency model. I also
did a minor
I think it would be great to have more nonce space with less merkle
calculation; keeping track of all possible versions of a block already
takes real RAM, real computation. Being able to change one bit in the
header and send out a new block for checking would ease our pool server
work by a real
The Satoshi client uses a pure reentrant mutexes model
As you presumably already know, the reference client doesn't attempt
to parallelise most operations at all. Chain download is entirely
single threaded.
--
Live
Hi Michael,
from what I have noticed, bitcoin blockchain download/verfication all
happens in 1 thread. (so multicores doesnt really help)
That said, I have never tried on an ssd.
What I do have is 6 SATA 6gbs configed as RAID0 Drives.
32gb of ram. ubuntu 64 (yeah I know), this runs upto 16
6 matches
Mail list logo
