I GOT DOUBLE MY MONEY BACK FROM HIM AFTER I SENT 0.00000001 AND GOT 0.00000002 !!!!!1111  Lol, but you got charged a 0.01 transaction fee to send the micropayment, and so did he. Gotta spend BC to make BC  |
|
|
|
I GOT DOUBLE MY MONEY BACK FROM HIM AFTER I SENT 0.00000001 AND GOT 0.00000002 !!!!!1111 |
|
|
|
|
Today is the day, no more entries after noon (-6:00 CST) today, good luck to you all with this evenings drawing.
|
|
|
|
The problem you outline exists in the current system. You restart your client after it's been off for a week. It immediately connects to Mallory's client and asks it for the last week's block chain. Mallory responds with one or two blocks, each with an appropriate hash. Now mallory can control your view of the network and transaction history. Oops.
Same problem.
With my scheme when you connect to a 'good' node later, you take the chain with the higher total difficulty instead of the longest block chain. A reasonable measure of the total difficulty under the current proof of work is the total number of zero leading bits in all the block hashes. In the case you mention, the attacker generates a better single block that some particular historical block but because it's followed by a bunch of easy blocks the total number of leading zero bits is much lower than the real block chain and hence the attack fails.
ByteCoin
The client makes at least 8 connections, kind of random. One would need to control all of those entry points. Not impossible of course, but one rogue client is one thing, but a bunch of good clients, how to do you formulate attacking all of them? |
|
|
|
For 32bit clients, this makes a huge speed increase (if your PC supports it) I was using a little netbook to test with, it could manage about 185 khash/s but his compile does 238 khash/s so over a 28% increase (what I saw in the 64 bit clients), so another thumbs up for this build. (Exe size is smaller too  ) |
|
|
|
I think he should really present to this devs to get credit for it and some BC because I'm going to send some to him for raising my khash/s up and beyond the already insane levels that I have. |
|
|
|
How do we know this is not a scam? Give us your IP to donate with or something so we can make sure you are reputable. I am scared to install it, it might steal my bitcoins.
If I were scamming, what incentive would I have to ask for donations knowing that those who used it would have their account emptied anyway. Frankly though, my username is far more of a verification of my authenticity than my IP would ever be  I can assure you the code is 100% clean. Sorry to be so skeptical, but there was a victim on this site when someone claimed to have compiled a CUDA client that used the graphics processor to hash. One guy fell for it and lost some bitcoins. But yes, if I get a chance I will look at the dlls I suppose before running it. Or, maybe you can release the project files and we can compile it ourselves? Point well taken, but the CUDA never materialized, this one actually does what he said it does. So if it is a scam, it sure is taking a lot of effort. |
|
|
|
no, that's definitely correct.
there is another possibility however... what processor is in your XP machine? if it doesn't support SSE2, it'll crash.
Tested it a Celeron machine (1.1 GHz) Good point, I'll see what the others do. |
|
|
|
Testing with the 32bit client, your build 32bit client build crashes sad to say on a stock system (Windows XP) anyway. Going to later test on Vista, 7, etc and report back.
] do you have the Visual C++ 2010 runtime installed? if not, that's why. Yes, straight from the download link on the previous page for x86. I looked through the error log a little, didn't spot anything that stood out. |
|
|
|
Does that apply for the x86 one also, since that's what I was using to test the 32bit build he had? [edit] I just checked, it was good for the 32bit |
|
|
|
|
Testing with the 32bit client, your build 32bit client build crashes sad to say on a stock system (Windows XP) anyway. Going to later test on Vista, 7, etc and report back.
|
|
|
|
Nice job, this is just my initial testing, but the 64 bit compile speeds up hashing by over 28% so far over the 32 bit counterpart. So for example, my 8-core system does (600 khash/s per core = 4800 khash/s) for normally, but now averages 5700 khash/s I'll certainly be sending some bitcoins your way |
|
|
|
It's not a scam, I decided to install it and see. Unless it's a very complex scam which waits for a while before stealing my coins This version has between 200-700 more khash per second on my machine. No missing DLL errors when you try to start it? |
|
|
|
How do we know this is not a scam? Give us your IP to donate with or something so we can make sure you are reputable. I am scared to install it, it might steal my bitcoins.
I'll guinea pig, I'm running it on a test system that has no balance yet, well trying to run, it won't start. |
|
|
|
see my previous post.
Feedback on performance is appreciated, bitcoins even moreso.
I keep getting a "MSVCR100.dll" not found error when trying to start it. I copied the file over from another system into the system32 folder, but the program still can't find it for some reason. Do we need the full Microsoft dev environment installed to test it? |
|
|
|
So, after a lot of experimentation, pulling out of hair, cursing of the developer, I finally managed to get a build of Bitcoin compiled under MSVC.
all optimizations are on including SSE2, LTCG and favouring of Intel64 (well hey, that's my processor)
Performance difference? The two builds I made (namely 32 and 64 bit) are practically equal in terms of performance - however, their performance is not equal to the stock build currently available.
On my quad-core with the stock Windows binary available from bitcoin.org I get about 1700k hashes a second. With the builds I produced under MSVC I get 2500K a second. Anyone interested?
I've got a spare server using a 8-core 64-bit Intel - 64 bit Windows 2003 server. I'd be curious if there is a difference from the stock, the machine currently does about 5000khash/s, I'd be curious if the 64bit native build would be better. |
|
|
|
knightmb - I'm just trying to work out how to create an automated Lotto and was wondering if you know of a way of identifying which account a payment comes from? For instance, if someone pays a fraction of a unit for the lotto, it can be returned and also so that the winner is automatically paid.
Yeah, at least from the GUI standpoint, if someone doesn't put in what BC address sent it to you, so I don't see a way to refund it. I haven't looked through the headless server version to see how the data is handled for that. Basically, someone would have to pay through direct IP and make sure they put in the from field, the BC address or else it's no different than a stranger in the street stuffing $20 in your pocket as you walk by and you never see that person again and don't know who it was. |
|
|
|
If only there were a gas station that accepted bitcoins! Maybe off topic, but I am working with a local bank to produce pre-charged cards (like Visa for example) that can be refilled with Bit Coins. So maybe one day you will be able to. |
|
|
|
Possibly related though: Can the bitcoin project survive if Satoshi is hit by the bus tomorrow?
Yes, all the source code is available, anyone can compile the client or modify it, fork it, etc. I meant an orderly succession, not a thousand forks of bitcoin. If Satoshi disappeared today? Then those that worked with him and wanted to put in the effort to run the project would be the natural selection logically. Otherwise, it just rolls down until someone wants to take charge. If that failed, I would considered heading the project myself if no one else was left that wanted to. |
|
|
|
|
Show Posts
