|
Added VIA padlock support, in git.
Completely untested -- I don't have the hardware.
|
|
|
|
Thanks for the inspiration. After reading this, I added VIA padlock support to my CPU miner. |
|
|
|
Updated the git repo (Linux) and http://yyz.us/bitcoin/cpuminer-installer.zip (Windows) to fix hash meter problems. Size: 1858209 SHA1: c9c2695b7f6708956dfe9b06e02a28fdc0cf46c9 MD5: 144e2c7d61d739a267bb623122e103e7 --algo=4way pretends to work, burns CPU and stuff, but only shows 0.00khash/s all time and some PROOF...false msgs, so i think it doesn't.
I fixed the 0.00 khash/s problem, but it looks like the algorithm might be returning incorrect hashes. I marked it "EXPERIMENTAL" in --help for now. |
|
|
|
Note that the khash/sec calculations are known to be buggy, so you cannot trust those numbers  Will try to fix that soonish, so people may accurately compare numbers with other installations. |
|
|
|
I'd be interested to see how well this works on Vista, XP, 7, ... complaining about "libcurl-4.dll missing" (although it's there at c:\CPU-miner\usr\i686-pc-mingw32\sys-root\mingw\bin\) it won't even start on 64bit XP&7, 32bit XP, am i missing something? Updated the installer at http://yyz.us/bitcoin/cpuminer-installer.zipDoes the problem still exist? EDIT: Here are the checksums for the latest Windows installer zipfile... Size: 1978933 bytes SHA1: fdea8a045db5e09b7441a4059fbdba186490e742 MD5: e60dbfb7c3b458c2a98e71cb295f9b7d |
|
|
|
complaining about "libcurl-4.dll missing" (although it's there at c:\CPU-miner\usr\i686-pc-mingw32\sys-root\mingw\bin\) it won't even start on 64bit XP&7, 32bit XP,
am i missing something?
Same here (WinXP) Clearly my installer-maker is having a problem Will investigate (though probably tomorrow). |
|
|
|
You should try it with tcatm's 4-way SSE2 SHA in sha256.cpp.
Added. Users may select this by enabling SSE2 instructions in their compiler during build, and then will select the 4way implementation, rather than the default 'c' implementation. Run "minerd --help" to make sure 4way is listed as an available option first; if not, you did not build with SSE2 enabled (-msse2, or many values of -march=xxx). |
|
|
|
I'd be interested to see how well this works on Vista, XP, 7, ... complaining about "libcurl-4.dll missing" (although it's there at c:\CPU-miner\usr\i686-pc-mingw32\sys-root\mingw\bin\) it won't even start on 64bit XP&7, 32bit XP, am i missing something? Try adding c:\CPU-miner\usr\i686-pc-mingw32\sys-root\mingw\bin\ to your PATH, then run minerd.exe? |
|
|
|
You should try it with tcatm's 4-way SSE2 SHA in sha256.cpp. It compiles fine as a C file, just rename sha256.cpp to sha256.c. I was able to get it to work in simple tests on Windows, but not when linked in with Bitcoin. It may have a better chance of working as part of a C program instead of C++.
I'll take a look. VIA Padlock support may also be similarly easy to integrate. |
|
|
|
Should I use a particular version of jansson? I installed it from git, and get the following compile error: util.c: In function ‘json_rpc_call’:
util.c:133:2: warning: passing argument 2 of ‘json_loads’ makes integer from pointer without a cast
/usr/local/include/jansson.h:188:9: note: expected ‘size_t’ but argument is of type ‘struct json_error_t *’
util.c:133:2: error: too few arguments to function ‘json_loads’
/usr/local/include/jansson.h:188:9: note: declared here
It's been tested with jansson 1.2 and 1.3 release versions. EDIT: If you lack jansson, current cpuminer.git will build an in-tree version. Thus, you may opt to fix the problem by... removing jansson from your system. |
|
|
|
|
Attached is a Windows executable build with mingw32. I'd be interested to know if it works.
run "minerd.exe --help" or "minerd.exe -h" to show command line options.
minerd.exe SHA-1 sum: 722fa3b956de3ed3438ed3294fe191f0d55c1514
minerd.exe MD5 sum: 9f75f8da7a5d02da1d45d46d4a032489
|
|
|
|
|
FWIW, the default bitcoin miner also does this -- it just doesn't print out when it "finds some zeroes", only when a real proof of work is found.
Thus, my CPU miner always shows when it stops working on a solution, and starts working on a new solution. Just giving you a bit more information on the whole process.
|
|
|
|
Nice work. But : DBG: found zeroes in hash:
6c1e0d9af9b06eab5aae7fbe058760708c1c7869870142b91b9c0ae300000000
PROOF OF WORK FOUND? submitting...
PROOF OF WORK RESULT: false (booooo)
[...]
DBG: found zeroes in hash:
c155613cbd70edad88bf56b06cbd788329a2a741b27ee78f25abdb2e00000000
PROOF OF WORK FOUND? submitting...
PROOF OF WORK RESULT: false (booooo)
I don't know if this is a bug or not. The miner has been compiled with cygwin, I don't know if it matters. Not a bug. The miner finds a hash with "several" zeroes in it, but then relies on bitcoin to do the full 256-bit hash < target value comparison. It's normal that some hashes will be found by the CPU miner, then rejected by bitcoin. We call those almost-solutions  |
|
|
|
URL: http://www.allvoices.com/contributed-news/7436607-paypal-demos-changefree-gumball-machineAt the recent Paypal X Innovate 2010 Developers Conference, held in San Diego, CA in late October, Paypal Labs showed off their proof-of-concept change-free gumball machine.
A clever combination of PayPal, QR codes (a type of barcode that can be scanned on a smartphone and can contain various kinds of information, including web links), smartphones and Twitter, the gumball machine instantly debited a PayPal account and dispensed a gumball to anyone with the capability to read QR codes on their mobile phone.
|
|
|
|
find a kid that died before he was 16 born in the same year as you (he wont have a SIN/SSN)
They give SSNs to new Americans at birth. |
|
|
|
This should be Wikipedia worthy... Yes? No?
Jeeze.. I sure hope so. Someone should revive the wikipedia page and add this article as a 'source' ASAP. It would be nice to have Bitcoin in wikipedia before interested readers start trying to search for it. The wikipedia page is pretty lame at the moment, and I agree with one commenter who says "smells like an advertisement" -- especially the Acceptance section. "Monetary and financial benefits" section is quite off-the-cuff, with many of the items easily open to question, or are quite plainly an opinion, not fact. I think bitcoin is best served by first having a respectable wiki page -- even if stored in From_Xenu or incubator -- then going back a third (fourth? fifth?) time to ask that the article be undeleted. Having a popular From_Xenu web page "riddled with facts", looking good, will do more to get a Bitcoin page into wikipedia than a million people posting "add it!" to a Talk page somewhere. Google searches will find the From_Xenu wiki page without a problem... |
|
|
|
Maybe Berkeley DB has some tweaks we can make to enable or increase cache memory.
Which of the ACID properties do you need, while downloading? Adding BDB records is simply appending to a log file, until you issue a checkpoint. The checkpoint then updates the main database file. Under a normal BDB transaction, you are guaranteed that each log record will be sync'd to disk platter, before the transaction commit succeeds. This is very strict, but required for full ACID. Enabling DB_TXN_NOSYNC still gives you a lot: "database integrity will be maintained, but if the application or system fails, it is possible some number of the most recently committed transactions may be undone during recovery" bitcoin can obviously recover if recent transactions are undone, so, it seems useful for this flag to be set for 100% of the initial block download. That leaves checkpointing, which is a balance between amount of work performed at checkpoint time -- number of records that must be copied from log to database file -- and wall clock time. Just gotta try some values and see what "feels" right -- maybe checkpoint every 10,000 blocks? |
|
|
|
It's not the downloading that takes the time, it's verifying and indexing it.
This is not true of many novice users, who say things like "well it took several hours to catch all the 90 000 blocks but finally it arrived" (quoted from one new user, on IRC, today). Bandwidthwise, it's more efficient than if you downloaded an archive.
Agreed. Compressed in an archive, blk0001.dat is around 36MB. Bitcoin only downloads the data in blk0001.dat, which is currently 55MB, and builds blkindex.dat itself, which is 47MB. Building blkindex.dat is what causes all the disk activity.
During the block download, it only flushes the database to disk every 500 blocks. You may see the block count pause at ??499 and ??999. That's when it's flushing.
It remains the download, not the verification, that has the highest variability of experience, where first time users see a delay of 30 minutes to several hours before the software is actually usable. Some P2P nodes may be extremely slow (I see high variability in latency and throughput for old blocks, and blocks larger than 512 bytes). End user bandwidth may be low, spotty or expensive. Firewalls are often a problem. I'm betting that the above complaint from a new user was due to a Microsoft firewall; but the point stands: large variance of network configuration and capability implies the P2P download impact may be far, far greater than impact of on-disk verification of 90,000 blocks. Doing your own verifying and indexing is the only way to be sure your index data is secure. If you copy blk0001.dat and blkindex.dat from an untrusted source, there's no way to know if you can trust all the contents in them.
Who said untrusted? The proposal is that you distribute blk0001.dat (and only blk0001.dat) in the bitcoin.org official client downloads. And of course the client will spend some time verifying blk0001.dat upon first use. This is unavoidable, and nobody has proposed changing or eliminating verification. Just shipping blk0001.dat with official bitcoin would eliminate several headaches that new bitcoin users continue to experience. |
|
|
|
|
Show Posts
