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 VM's
> 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 Secu
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 amo
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 t
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 che
> Really lightweight clients (like Bitcoincard), clients with shared
> private keys (electrum-style), or brainwallets - will ask the following
> question quite often to "supernodes": Given my public keys/addresses,
> what is the list of unspent outputs. i think it would make sense to
> include such
> 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 b
7 matches
Mail list logo
