By your analysis, bitcoins should have been super expensive when they were being mined by CPUs.
No. You might want to study Bitcoin's concept of difficulty to understand why. |
|
|
|
On monday morning I hsve done a deep analysis
I'm quite sure my analysis beats yours  Here it is: There are ASIC based mining rigs coming online right now, and there's a startup that will within a few months sell these to anyone who wants them. An ASIC rig is mining coins at an order of magnitude cheaper than GPU rigs. Thus, the fundamentals backing bitcoin (= how cheap can a miner sell them and still make a profit) are currently dropping by a factor of ten, or so. The upside is that this is the last (CPU -> GPU -> ASIC) such disruption for the foreseeable future. But feel free to practice your http://en.wikipedia.org/wiki/Apophenia - it's fun to watch |
|
|
|
My older C2D 2.0GHz laptop gets 155 Kkey/s with a single thread. Maybe OpenSSL isn't being built with the assembly code enabled? Interesting. I would be surprised if the Apple default Snow Leopard OpenSSL installation (0.9.8) wasn't optimized though - the Macports version (1.0.0d) was after all slightly faster. I didn't verify the compile flags used though. Maybe we should just wait for other Mac users to report in :) My system could possibly have other issues. Tell me about the crash!
Sure. Not really understanding the different options I tried starting it with a really low value for worksize: $ ./oclvanitygen -w2 -d0 1pattern
Difficulty: 15318045009
vg_ocl_context_callback error: [CL_INVALID_COMMAND_QUEUE] : OpenCL Fatal Error : Kernel execute caused an error that invalidated the queue (0x1004103b0). This may be due to a resource allocation failure at execution time.
vg_ocl_context_callback error: [CL_INVALID_COMMAND_QUEUE] : OpenCL Error : Failed to wait for events! Event 0 in waitlist failed. Invalid command queue
vg_ocl_context_callback error: [CL_INVALID_COMMAND_QUEUE] : OpenCL Error : clEnqueueNDRangeKernel failed: queue (0x1004103b0) has been invalidated.
clEnqueueNDRange(2): CL_INVALID_COMMAND_QUEUE
(followed by the GPU information I posted above) With a 9400M, the number you got might not be too bad. It probably needs tweaks to work well on smaller laptop GPUs, and I don't have one to test with. I'll guess that it has long, uncomfortable display lag? The work unit autoconfiguration certainly hasn't been tested with your GPU, and you might get performance or responsiveness improvements from command-line tweaks like -w256 or -g512x256 or -b1024. It needs a built-in benchmark, among other things.
Really bad lag, yes. Just for reference, for anyone who wants to start fine tuning, I ran (very briefly) all your examples above: - -w256 - no obvious difference in speed or responsiveness
- -g512x256 - ~15% slower, more responsive
- -b1024 - no obvious difference in speed or responsiveness
|
|
|
|
First, congrats on getting oclvanitygen to run! What GPU are you using? The key rate is probably a lot slower than it could be, but at least the OpenCL compiler isn't crashing.
Regarding the OpenSSL warning, that check is a compile-time one, so switching out the shared library won't stop the warning. This brings up a potential issue: I thought that between OpenSSL 0.9.8 and 1.0.0, a bunch of changes were made that broke binary compatibility. To the effect that attempting to build against the header files for 0.9.8 and link with a 1.0.0 library would cause problems. While it doesn't seem to be crashing for you, it should run at about twice the speed you report. Anyway, when building from source, you want to use the header files for 1.0.0.
What we really need is a set of pre-built binaries for OS X, with the 3rd party dependencies static-linked.
Yeah I just managed to fix it, posting as a reply to you now instead of yet another edit to my original post It was indeed me just being rusty at writing makefiles. For those who install a newer version of OpenSSL using Macports the Makefile needs to look like this: LIBS=-L/opt/local/lib -lpcre -lcrypto -lm -lpthread
INCL=-I/opt/local/include
CFLAGS=-ggdb -O3 -Wall $(INCL)
OBJS=vanitygen.o oclvanitygen.o pattern.o
PROGS=vanitygen
TESTS=
all: $(PROGS)
vanitygen: vanitygen.o pattern.o
$(CC) $^ -o $@ $(CFLAGS) $(LIBS)
oclvanitygen: oclvanitygen.o pattern.o
$(CC) $^ -o $@ $(CFLAGS) $(LIBS) -framework OpenCL
clean:
rm -f $(OBJS) $(PROGS) $(TESTS)
It makes no difference in speed compared to using the right lib and the wrong header files (I think there was a 20% speedup or so between the 0.9.8 and 1.0.0 libs though) - but since I'm on a laptop I have no opinion on what's good or bad. My MBP is a 2.53GHz C2D with an NVidia GeForce 9400M. This is the output I can get from oclvanitygen by playing around with the parameters and crashing it Device: GeForce 9400M
Vendor: NVIDIA
Driver: CLH 1.0
Profile: FULL_PROFILE
Version: OpenCL 1.0
Max compute units: 2
Max workgroup size: 512
Global memory: 268435456
Max allocation: 134217728
Agree about pre-built binaries from a trusted source for those who don't want to spend a few hours going from no build environment to a working one I like doing it since I was a developer many years ago and want to prove to myself that I haven't forgotten everything. In this case it took way too long to figure out I had put the include path flag at the wrong place ... |
|
|
|
- Edit: Mac OS X platform support and makefile, added by dinox
Seems to work fine - thanks! I built in on my MBP (had to install pcre first) and tried both vanitygen (~100kk/s - 1 thread, ~170kk/s with 2) and oclvanitygen (~140kk/s) although I haven't imported any keys into a wallet and used them for transactions. I did fail building it towards a newer version of OpenSSL (1.0.0d, installed via macports) though, even though I added both a hardcoded lib path and the correct include paths to the Makefile. I guess it's been too many years since I developed anything in C. (Or did I succeed and it's just the version check prompt that gets its knowledge from elsewhere?) edit: This. $ otool -L vanitygen
vanitygen:
/usr/lib/libpcre.0.dylib (compatibility version 1.0.0, current version 1.1.0)
/opt/local/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
$ otool -L oclvanitygen
oclvanitygen:
/usr/lib/libpcre.0.dylib (compatibility version 1.0.0, current version 1.1.0)
/opt/local/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
/System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL (compatibility version 1.0.0, current version 1.0.0) vs $ ./vanitygen
WARNING: Built with OpenSSL 0.9.8l 5 Nov 2009
WARNING: Use OpenSSL 1.0.0d+ for best performance
Vanitygen 0.16 (OpenSSL 0.9.8l 5 Nov 2009)
Usage: ./vanitygen [-vqrikNT] [-t <threads>] [-f <filename>|-] [<pattern>...] I've also tried export DYLD_LIBRARY_PATH=/opt/local/lib/ in the event it was a runtime loading problem but it didn't change anything. |
|
|
|
Not giving you my private keys for storage, but using the data stored with you together with my local secret every time a key is needed.
But how would you see that work with a web service? You could implement a large part of the Bitcoin protocol in JS, but if it is served from the wallet provider, it could steal any key that you enter by injecting a keylogger into the JS as well. That's the most common argument leveraged against LastPass, and it's indeed valid (see below). The solution, so far not implemented anywhere, is to sign a hash of the JS snippet in question and have that verified by the client. When the code needs an update it has to be vetted before clients approve a new hash or signature. I believe this is on its way into the HTML specifications but I haven't looked for some time. If we control the client implementation (Android, PCs) it's however implementable already today. In the LastPass case, they are considered trusted (reputation, company) and the architecture is meant to protect against hacking instead. They take great care to make sure their systems serving up the JS in question aren't easily manipulated, and if a hacker were to extract their databases they still cannot do anything with them since everything is encrypted and only the end users have the corresponding keys. |
|
|
|
What would make you feel more comfortable with the idea? Not giving you my private keys for storage, but using the data stored with you together with my local secret every time a key is needed. This would be similar to how LastPass handles passwords (they're not stored with them, yet it's "like" if they were) and give the same security as Wuala has over Dropbox (employees cannot, ever, see your content). |
|
|
|
I have an idea to create new software product: FTP service on user's PC for Bitcoins.
Many of us have ample hard drives and broadband Internet connection with unlimited bandwidth. I propose to create web-fronted for FTP-server (e.g. FileZilla Server) that allows other users to buy space on your HDD and store files using convenient FTP protocol. If you keep computer on for 24h and have normal connection speed I think many people would like to pay you small amount in bitcoins instead of buying expensive and non-anonymous service like DropBox. For example I am ready to sell 300 Gb right now and would buy extra HDD if there will be enough demand.
Is idea worth?
See Wuala - http://www.wuala.com/ You can trade storage (or buy, using bitcoins - and it's client side encrypted. |
|
|
|
Any feedback would be appreciated....
"USA based" I don't trust any data being stored inside US borders, sorry  |
|
|
|
... and those buyers will lose their accounts with the site, right? I thought that was the whole point of them having to "verify" everyone. Is it possible to cancel a transaction?
Yes, it is, however you should not do this unless you have a VERY good reason (e.g. your bank is unable to send the payment to the seller's bank). Also, you cannot cancel the transaction by yourself, but you can request the other party to agree to cancel it. To send a cancellation request to the other party go to your Transactions and use the "Cancel transaction" button for the relevant transaction.
You will be asked to type in the reason for cancellation, that will be then emailed to the other party of the transaction. If they deem your reason fair, they will cancel the transaction. Otherwise the only way to cancel it is to email BitMarket. Please remember: buying coins is not a game, these are real people you deal with and by putting an offer out there you give your word that you will fulfill it. If you abuse the Cancel option your account will more than likely be suspended and you may be banned from the exchange.
|
|
|
|
I may even have re-used the pw or that my very simple pw was guessed somehow http://lastpass.comSeriously - once you start you'll never understand why it took you so long. One new completely random password for each site. Always. (And just to pre-empt some common responses from those who don't verify what the site is about - no - your passwords are never transmitted to nor stored with LastPass) |
|
|
|
|
Sorry for your loss. I have no insight to give, but I've bought bitcoins on bitmarket.eu several times without the same happening to me.
Actually, last time I did I also wanted to change my payout address - and that could only be done by also verifying a mail sent to my registered email address. So, if your coins were transferred to an address you don't own then someone must have access to your email as well.
|
|
|
|
Right now I'm afraid that it's going to be a few people hanging out, not knowing what to do with themselves.
I can't find enough information about the conference to figure out what's going on or whether it's worth my time and money to go.
Sorry Bruce. As discussed in a previous thread, rename the current event "Bitcoin meetup" and from there set up organization for a larger conference. I just visited the web site a few days ago and it's exactly the same as when this conference was announced months ago. |
|
|
|
and the foreign company delivers that pornography to the US, the company committed a crime under US law
"Foreign" people and companies seldom care about US law though since it doesn't apply to them. It might make travels harder for the future, and some laws (copyright etc) are by agreement similar in many countries, but your example wasn't the best. Who knows - maybe the content of your post just broke a law in my country. It's neither your nor bitcoin.org's problem though |
|
|
|
|
Just to add then that both scan in the same amount of time (instant) for me on a Sony Ericsson Arc using NeoReader.
|
|
|
|
Comments anyone?
Maybe providing a brief description of how users can backup their mobile wallets? Doesn't really need to be secure, I think most are more worried about bugs wiping them atm than having their mobile stolen. edit: Btw, after brief testing (rcv, no send yet) I must say I really really like this client. edit2: As I mentioned in an android-client donation thread on the main discussion board a few days ago I'd like to see some donation sharing between the different client implementers and BitCoinJ though. It'd be great to hear Mike's views on this as well. |
|
|
|
fxspoke is thinking about printing bitcoin stickers so I created a bitcoin extreme design qr code. it links to bitcoin.org.
Pretty! i wondered about what the OP said and so I created a bitcoin regular design qr code. it links to bitcoin.org.
Less pretty. |
|
|
|
it makes the whole thing seem like a cheap marketing scheme, or worse - feeds the ponzi/pyramid arguments (stupid as that may be) I actually refuse signing up to TradeHill since I do not support referral schemes for exactly this reason, and I think anyone dealing with anything that might get published should remove referral tags completely. It just looks bad. |
|
|
|
|
Show Posts
