 Show Posts
|
|
Pages: [1] 2 3 4 5 6 7 »
|
|
I just tested Electrum 2.0 though a PPTP VPN and it works fine. Are you sure your VPN is configured correctly? I do not think this is an error on Electrum's part.
|
|
|
|
It will look like this in settings:  I will initially parse the welcome message for bitcoin addresses but later this may be added to the protocol. Stay tuned. |
|
|
|
|
I am looking to work on a small addon to Electrum just to learn the client. I need something cool to do.
Would you be interested in a new field, similar to the "fee" field, but instead tips the electrum server which you are currently using?
|
|
|
|
What is the command to display current gap limit of an Electrum 1.9.8 wallet? Thanks.
wallet.gap_limit |
|
|
|
Just want to state a fact. This guy lomax has done something both bitbond and gigamining has failed at doing. I invested 49.9% in bitbond, 49.9% in gigamining and 0.2% in 007. Even after 6 months I have got a lot more from 007 than from any of those scammers. I just want to thank you for the very good work you have done, for your honesty to pay us back and I really hope you find a different way to make business in bitcoin in the future. Bitcoin needs non-scammers like you! Regards, dinox PS. Thanks for my 0.2% btw. I highly regret I did not invest 100% with you  |
|
|
|
|
I would say it's latency, and not the size of the block header, that matters.
|
|
|
|
|
This is then equivalent to a futures contract, right? Parties agree at making a transaction in 6 months at 5.11usd/btc.
25 btc is way too low, good luck finding your counterpart.
|
|
|
|
If BFL scams you or it gets lost in shipping, you refund the buyer full amount, right?
Dang, dinox has used the word ' BUY'! Congratulations to the lucky winner! Oops, he forgot to quote the current price. Got away on a technicality!  ...someone posts "BUY" in this thread with the current price. |
|
|
|
|
at 0.1$/kWh you can buy 2 500 000 kWh at 250 000$ or enough for running those BFL mini rigs 50 years. I bet the solar panels is dead way before 2062.
If you promise use wall power instead of solar your project actually looks good.
|
|
|
|
|
If BFL scams you or it gets lost in shipping, you refund the buyer full amount, right?
|
|
|
|
OK. If btc price goes down we get 1025 btc back and you get some from value difference.
If btc price goes up we get 1025 btc bad and you have to pay some due to value difference.
How in earth are you going to earn anything if we hold btc in escrow?Edit: Ah, you are not asking for a loan, you are asking for a CFD. Forget my questions  Edit2: I still don't get it. Since first post says 100% guaranteed, we get 1025 btc back no matter what happens? |
|
|
|
|
What restrictions do Blizzard set on a SC2 guest pass?
|
|
|
|
|
It took me 6 mins from PM to get a code. Top notch, thanks mate!
|
|
|
|
The security afforded by this scheme comes at the cost of not being able to pool together the patterns desired by different clients into a single list, which would be dramatically more efficient. Every work unit executed by the service would end up being specific to a single client. If there were some way around this, it would make the service much more practical.
If we had a trusted pool server, it could supply each "miner" with a list of patterns and a public key which only the server knows the public key of. When a match occurs, it's controlled by the server and if it is correct, the miner get's another public key and server sends the vanity key and corresponding private key to the requesting user. We do have to trust the server to not steal the public keys, I don't know if this is a big issue. |
|
|
|
|
Hmm, if I knew C I would code a switch where you use an existing pub-key as seed, and vanitygen tries new keys by adding to that key. That would make it safe to help people find a key, without you having a way to fraud him.
|
|
|
|
|
Really great idea, following this thread!
|
|
|
|
New version posted. This includes a lot of changes. - Bugfix for private key encoder. It was possible for it to output a shorter-than-expected private key. If you have a private key that does not start with a 5, or is less than 51 characters long, don't use it. If you have such a private key with a bitcoin balance, contact me for assistance.
- Oclvanitygen #pragma unroll has been removed, for Rassah. If you experienced a crash with a Radeon card, but safe mode (-S) worked, this should fix the problem.
- Oclvanitygen work size autoconfiguration now sets more reasonable limits for smaller GPUs.
- Numerous performance tweaks to oclvanitygen, including AMD BFI_INT instruction patching.
- Windows binary package now includes x64 build: vanitygen64.exe. This binary runs about 50% faster, if you have a 64-bit edition of Windows.
I never knew just how slow the 32-bit Windows build was until recently, and must apologize for not posting a 64-bit build sooner. 64-bit arithmetic makes a huge difference. The Windows binaries for 0.17 are also built and linked with more MSVC optimizations enabled, and now include statically-linked OpenSSL. Despite all of this, the x64 Windows build seems to run about 10% slower than an equivalent Linux build. Upgrade to OS X Lion fixed my problems, getting 1.6MKeys/s now with my Radeon 6490M. One question tho: Why do I get 2*0.9kKeys/s when throwing two threads of oclvanitygen at the same GPU, and only 1.6MKeys/s when running one thread? Edit: Adding one more thread (for a total of 3) gives me 2M+, but 4 threads only gets about 1.6M. |
|
|
|
I'll say it again: You can modify it anyway you like, the only thing you can't do is post the code or your modified code under a different name or distribute it any other way than the main distribution channel for the project.
Uhmm, but that means we can't fork your project on github and how is we then going to send you pull requests? |
|
|
|
Tell me about the crash!
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.
Intresting it works on OS X for others, it's probably my MBP which is the problem. I'm throwing 10.7 Lion at it now so let's see if that fixes the problem... |
|
|
|
|
