I've tried the cpuminer version 0.2.1 on a VIA Nano machine. I used the "via" algo with a bitcoin running on the testnet. The miner worked, but the results generated seemed to be wrong, debug output pasted in below. The system is a 64bit Debian unstable machine with a VIA VB8001 motherboards. It's running a stepping 2 VIA Nano. The kernel seems to do a workaround for Nanos with that stepping, perhaps something needs to be done in the miner code, as well. HashMeter(0): 16777216 hashes, 1589.69 khash/sec
DBG: found zeroes in hash:
9ec42e51b34b69fc2f7209f3e334afcfa563d1da21647832cd2b312c00000000
HashMeter(0): 6644792 hashes, 1606.76 khash/sec
PROOF OF WORK FOUND? submitting...
DBG: sending RPC call:
{"method": "getwork", "params": [ "000000016f643cccfaa9574cd1a3369a23da6452fcf296587e4da572a008520300000001f1071376c66751bede719672dd1e9e3b2a3daeec709fc5bcaede21364748d93a4cf93ea21d05106000000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000" ], "id":1}
PROOF OF WORK RESULT: false (booooo)
Actually, it looks like it is working, to me. As explained in this thread, cpuminer searches for an approximate number of leading zeroes in the hash. It then submits that hash to bitcoin, for final verification. Thus, it is normal for cpuminer to find several almost-solutions, before finding a real solution, depending on current difficulty. The official bitcoin client works this way too -- it stops hashing when a certain amount of zeroes appear. However, it does so silently, whereas cpuminer print something. |
|
|
|
And yes, the checksums, actually the SHA1 hashes are on the bitcoin.org frontpage (is it me or does the bitcoin community have a bias towards hashing everything XD)
As a side note, those SHA1 hashes on bitcoin.org are almost useless. There is no PGP signature, no chain of trust, so a hacker could easily replace the binaries and hashes. Has anyone verified that the hashes remained unmodified after bitcoin.org downtime, for example? There's no ongoing record of the binaries' hashes, in the forums or elsewhere, so who knows. I'll continue to build my own client from source code, after reviewing the diffs, thankyouverymuch  |
|
|
|
I sent $100 cash to Morpheus to convert into MtGox $, but it never arrived. I mailed it from a public mail box, so it wasn't stolen out of mine.
I can't think of a time that I've ever had first-class mail get lost before.
Did you use USPS delivery notification? |
|
|
|
I have a paxum account so if anyone wants this let me know and I'll set up withdrawal to paxum.
not really seeing the difference between paxum and paypal Yeah, when going from mtgox -> paxum -> mastercard or mtgox -> paypal -> mastercard, it's pretty much the same. I suppose the only real difference is that mtgox will probably have a difficult time getting and using another paypal account effectively (even if it's withdrawal-only?) |
|
|
|
What about Pecunix? The transaction fees don't seem to be that bad.
pecunix is cool, but its a pain in the ass to setup an account and use it I think the exact opposite -- creating a Pecunix account is free, and all it requires is filling out several HTML form fields. Couldn't be easier. Using the "Payment PIK" is slightly more annoying, but not much so. |
|
|
|
I wonder what this might mean: checking for json_loads in -ljansson... no
checking for pthread_create in -lpthread... yes
./configure: line 4305: syntax error near unexpected token `LIBCURL_CHECK_CONFIG'
./configure: line 4305: `LIBCURL_CHECK_CONFIG(, 7.10.1, ,' Any ideas? autogen.sh did not find the necessary libcurl autoconf magic to build your configure script. Thus, instead of transforming the macro LIBCURL_CHECK_CONFIG into something useful, it left it as-is. So, your libcurl install is missing some pieces (or autogen.sh cannot find them). |
|
|
|
I highly recommend the site for LRUSD -> PPUSD transfers. Never tried going the other way, though. |
|
|
|
I think the tor network is slowly dying
torservers are breathing a bit of new life into it. |
|
|
|
I personnaly think the best would be if each store could act as a bitcoin bank. Basically you would have a bitcoin account in the shop, and you'll use with conventionnal banking-like transaction for every day purchases. You would only transfer bitcoin something like say one in a month, just to fill up your account. Such accounts could also use David Chaum's digital cash, so that stores could act like private money issuers.
Most stores offer some sort of gift certificate, gift card or store credit. You just need to convince the store to accept bitcoins for store credit. |
|
|
|
Post blocks to alt.bitcoin |
|
|
|
I can do end to end encryption with IPv6? How do I verify the person at the other end?
Google for IPsec. |
|
|
|
|
Patch updated for latest SVN.
|
|
|
|
|
Patch updated for latest SVN.
|
|
|
|
|
Patch updated for latest SVN.
RPC has been renamed to 'xlisttransactions', because mainline is now including an incompatible version.
|
|
|
|
|
QR-codes are well supported by open source tools, and are in more common use.
|
|
|
|
Qr codes are a workaround that likely won't need to exist after Android 2.3 because that version supports Near Field Communications protocols. It's a ten cent chip added to the smartphone that would make the camera on the phone the expensive hardware. If the consumers could reasonably be expected to use QR codes, then the credit card companies would have them everywhere already.
NFC could easily transfer these strings too... |
|
|
|
Today's #bitcoin-dev featured an interesting discussion of mobile phone use, centered around the following use case: - customer walks into real-world stores, selects several items, and walks to cashier to check out
- cashier displays QR-code on customer-facing screen
- customer uses mobile phone to take picture of QR-code
- mobile phone displays "Big Box Store Corporation, Inc, requests a payment of 300 BTC. Do you agree? Yes / No"
- customer agrees (or cancels the sale), triggering BTC transfer from customer to merchant
As such, tcatm, nelisky and I started typing out notes for APIs at http://www.bitcoin.org/wiki/doku.php?id=phone_api I'll let tcatm or nelisky talk about payment requests if they wish, but I wanted to focus on defining a QR-code specification that people could start using immediately. Each of these is a text string in the style of RFC822 headers (“key: value”), where “value” is further separated by semicolons. Strings containing semicolons or spaces may be quoted with double-quotes ("). Double-quotes themselves are escaped in the obvious way, with a back-slash. 1) Bitcoin address. Not directly related to the purchase-via-mobile-phone scenario just described, but obviously necessary. bitcoin-address1: name="John Q. Public"; pubkey=1LGpwDU5djqsR1X14Tcass3y9fULTzxJq3
Using this QR-code, you may share bitcoin addresses with others via mobile phone. Use this QR-code on the forum or your website, to give out your bitcoin donation address!2) Merchant request for direct payment via bitcoin network. btcpayment-request1: name=“My Bitcoin Inc.”; pubkey=1LGpwDU5djqsR1X14Tcass3y9fULTzxJq3; amount=300
Using this QR-code, the mobile phone knows enough to ask the user if they wish to pay 300 BTC to My Bitcoin, Inc. at the given bitcoin address. Presumably the mobile phone has the ability to make bitcoin payments, either directly (a lightweight bitcoin client) or indirectly via a payment API such as this. 3) Merchant request for indirect payment via a custom payment processor. payment-request1: merchant=1234; name=“My Bitcoin Inc.”; tx_id=1234bacd;
payment-processor=http://mtgox.com/apiv1; api=mtgox; amount=300; currency=BTC
Using this QR-code, assuming that the mobile phone app is aware of an API known as "mtgox", the mobile phone knows enough to ask the user if they wish to pay 300 BTC to My Bitcoin, Inc., using the specified custom Web API. The "1" suffix implies version 1 of that QR-code. An incompatible change would imply "bitcoin-address1" becomes "bitcoin-address2", etc. |
|
|
|
Yes! They work at ATMs.
Very nice... bitcoin-to-ATM would be fantastic. Making bitcoin successful involves a lot of this "last mile" type of solution. |
|
|
|
More generally, we could also consider this:
dbenv.set_lk_max_objects(10000);
dbenv.set_errfile(fopen(strErrorFile.c_str(), "a")); /// debug
dbenv.set_flags(DB_AUTO_COMMIT, 1);
+ dbenv.set_flags(DB_TXN_NOSYNC, 1);
ret = dbenv.open(strDataDir.c_str(),
DB_CREATE |
Or DB_TXN_WRITE_NOSYNC. Writes, but does not sync. Should be fast since almost every OS (and hard drive!) has a writeback cache. |
|
|
|
|
Show Posts
