Testing on a clean WinXP 32bit in a VM

After installing MinGW, I should set MINGWPATH in set_vars.bat to C:\MinGW\bin to be able to proceed. The default is 'C:/MinGW'. Am I missing something?

@Ruudsy

Just put the server definition after all other options

Mike, I obviously failed to explain it properly. Whatever headers and coinbases are presented to an SPV client, there is a rule  stating that at block 100 000 there should be strictly  5 000 000 BTC or less in circulation. So, a chain of headers which sums above that should be considered invalid.

Excuse me for commenting so late on this topic. I just wanted to note that even if miners perform this, they can't inflate above the predetermined issuance schedule, i.e. at block N 'never greater than' money in circulation is easily calculated. Effectively, it's only possible to reassign already destroyed funds.

rDNa6N2YsP9SGNoJdbNj1McViMDyxkdqsB

Perhaps piuk will provide more details about the double-spends page. I'd guess that it lists transactions that spend inputs which are used in previously known (to blockchain.info) transactions. The majority of them should not enter a block. Every SDICE profit which is double-spent and confirmed, as with the ones you noted, is a dent in the edge.

Yes, I still maintain the miner. It is now modular, i.e. you can implement your own hardware or work-source types. I just haven't released a py2exe recently (since BFL support actually) - POCLBM doesn't look so popular anymore and works fine for anyone able to setup python + pip and pull sources from github.

Whatever you improve for MacOS is welcome.

I explicitly asked for acknowledgement in a separate message and received one. It was not cryptographically signed though. I guess no respectable business will ever use such funny things as asymmetric cryptography these days.

intel core i7 860 (4 physical, 8 logical cores)

bitcoin-qt built with gitian-builder from sipa/turbo rev 3ccb06f5ae538260817b6ef474f93029be41a64d


Ubuntu 12.04 64 bit, SSD A-DATA SX910 256 GB

64 bit, no -par (default), default cache

first 193000 blocks from bootstrap.dat - 11m:40s CPU time

real    9m50.565s
user    10m47.800s
sys     0m56.548s


64 bit, no -par (default), default cache

loading from blk000x.dat, up to arround block 211100

-loadblock=blk0001.dat -loadblock=blk0002.dat -loadblock=blk0003.dat

1 GB peak memory, ~80% average CPU usage, total CPU time 3h:16m

real    41m30.004s
user    196m43.378s
sys     2m47.834s

debug.log.ubuntu.12.04.x64.7z




Windows 7 Professional x64, two Seagate 512 GB HDD in RAID 0

-loadblock=blk0001.dat -loadblock=blk0002.dat -loadblock=blk0003.dat

default cache, with '-par 8', initially it seemed to run in single thread mode - first 193 000 blocks loaded significantly slower than on Ubuntu (same hardware), reason perhaps is slower storage.

After block 193000 the average CPU utilization rose to ~75%. Looking at threads, there were 16 threads executing same code of which 8 were actually active.

92 minutes real time, 6h:05m CPU time, 72% average CPU utilization, 235 MB peak memory working set

I then tried with '-par=4' and setting CPU affinity to physical cores only. Now there were initially 12 threads at transaction crunching, with again only one actively processing pre-SatoshiDice blocks.

debug.log.win32.7z

How about making difficulty re-target optional parameter for mining.notify?

Again, new version is up. Main difference is it will always prefer Stratum now - for example if there is http:// specified, but server returns stratum address, it will be used.

As always, some small fixes were needed. Please update with the latest version.

A new version is up with support for Stratum. See https://bitcointalk.org/index.php?topic=108533.0


I am also planning multi-miner support (GPU) as well as FPGA support.

Ok, 058-2 works for me. If cp866 is copied to 058-1 Electrum_SysFiles it works too.

But is there any explanation why cp866 is needed at all? R047a lacks it and still works fine.

@flatfly:

Just quick update on the "not connected" problem. Tried to debug it on Windows 7 x64, elecwin 0.58 portable.

When trying to connect:


For some reason trying to manually import encodings.idna fails to load unicodedata.pyd.

Also, for some reason running packed python.exe (2.7) as console:


Last working version for me is elec047a. Next I got is elec048b and it has the problem.

I'll try to figure this out later, no more time for now.

There are features already implemented which will make the recent heist a nightmare of the past. The problem is they can't be deployed before the majority of hashing power agrees.

I am not vouching for a particular one - just trying to convince you that you should start mining at a pool supporting any of the solutions.

Unfortunately Deepbit is currently supporting NONE of them.


http://blockchain.info/p2sh

New windows binary (2012_02_05) is out.

Changes:

-- support for proxy servers including socks5 (hint: tor)
-- fixed bug in calculation of true target

Please see https://bitcointalk.org/index.php?topic=1334.msg732081#msg732081

The problem is triggered by a feature in poclbm I suspect most of the users don't care at all - detecting if a real block is found if mining against a pool. The feature was introduced back in July 2011 and was fixed twice even before being released. Apparently, the fix was not good enough and with the last difficulty adjustment the problem showed up again.

I sincerely hope it is really fixed now. Latest github should be OK. I plan a windows binary release for today.

Hmm... I don't rebroadcast transactions in order to keep more of the fees for myself. But fees are denominated in... BTC. By not supporting the network and eventually breaking it, BTC will tend to have value of... right, zero. So, I don't really have an incentive to maintain cooperating node?

Confused.