|
Abe is fast; good work John! It took barely 90 minutes to import the chain on my cheap laptop.
|
|
|
|
|
Your entire premise is that old keys/users are more trusted. It is dangerous to assume this. An attacker with much less than 50% of the computing power could outrun the legitimate chain on the simple merit that he owns (or illegitimately gain access to) an old enough key...
It would also further reduce the pseudo-anonymity of Bitcoin by correlating all blocks owned by one person by looking at which key signed them.
And it would unfairly advantage early-adopters with old keys, who are already advantaged by having mined a lot of coins at a historically low difficulties.
|
|
|
|
Correct me if I'm wrong, but if you have a miner that mines 50 BTC, you receive those 50 BTC by generating a new key pair, and broadcasting your block solution and the public key to the network. The network then associates 50 BTC with that public key. Therefore, your key pair is associated with that generation, and thus, the time the generation transaction occurred.
Correct. In this case, my 2nd paragraph is my answer to you. |
|
|
|
It depends. If the workload is purely ALU-bound or FPU-bound and there are few instruction interdependencies, then each thread of a HT core should deliver exactly 50% of the performance of a single thread running on it, as they share execution units. IOW HT doesn't help at all increase performance.
However if the workload is memory-bound, if execution units are mostly idle, then each thread of a HT core should deliver about 100% of the performance of a single thread running on it. IOW HT doubles performance.
For real-world workloads, the number falls somewhere in between 50% and 100%. CoinHunter reporting 90% means his mining algorithm is mostly memory-bound.
Real-work workloads gain 10-30% from HT. That's tested results, not theoretical stuff from whitepapers. All time absolute record that I have seen is around 40%. You did not read me correctly. You are talking about a different percentage scale. When I say "50% of 1 thread" it means "0% performance gain from HT". When I say "100% of 1 thread" it means "100% gains". IOW, you agree with me. |
|
|
|
I apologize in advance if this has been discussed already, but my search skills can be pretty terrible. Wouldn't it be possible to partially fix the 50%+1 issue by having clients weigh how much they trust the source of new (and maybe even old) blocks? Basically, every time you generate 50 BTC, you get a new key pair with it, right? This key pair is associated with a generation time. If, when miners generate new blocks, they also demonstrate possession of their oldest key pair by signing something with it, we could decide to trust them more, since they've been around longer. This isn't perfect, but it'd at least up the requirements for prospective attackers. Note: This is half-baked, so please go easy on me.  I've no idea, for example, if it's too much of a burden on the network (particularly lightweight clients who don't have the full blockchain) to verify age like this. Key pairs are not associated to a generation time. They are created at will and are independent of anything else. If you are talking about signing blocks specifically with keys there associated to previously solved blocks, then how would the bootstrapping mechanism work? Which key would a first-time solver use to sign the block? |
|
|
|
Right, but did you actually rent office space? Even if you did, Regus only allows 2 days of office space use per month ("virtual office" package) or 5 days/month ("virtual office plus"). It doesn't change my opinion that you are a little deceptive in prominently calling it "your office" on your website... |
|
|
|
Clock for Clock AMD PHENOMs seem the fastest option currently. However factoring in HyperThreading seems to put it big in intels favour. I haven't researched why yet, but a hyperthreading core gives nearly 90% of a non HT core on my I7-920.
The only way I can explain that is if you were using two HT cores on separate physical cores. Two HT cores running on the same physical core simultaneously, and both delivering 90% of a physical core doesn't appear to make sense. Can anyone confirm this behavior? It depends. If the workload is purely ALU-bound or FPU-bound and there are few instruction interdependencies, then each thread of a HT core should deliver exactly 50% of the performance of a single thread running on it, as they share execution units. IOW HT doesn't help at all increase performance. However if the workload is memory-bound, if execution units are mostly idle, then each thread of a HT core should deliver about 100% of the performance of a single thread running on it. IOW HT doubles performance. For real-world workloads, the number falls somewhere in between 50% and 100%. CoinHunter reporting 90% means his mining algorithm is mostly memory-bound. |
|
|
|
Campbx is the only trade I trust.
Also, Since I live within 6 hours of their office in atlanta, if anything shady happens I will personally drive down there and BURN ATLANTA TO THE GROUND
Except CampBX has no physical presence at their published address. Google it; it is the address of a generic mail forwarding service with hundreds of companies listed in this suite 300. It's Keyur's right to use this service, but he is a little deceptive in claiming it is "CampBX's office". Edit: suite 300 is managed by Regus who also provides "phone answering services", "virtual offices", and "shared meeting rooms"... Nothing very permanent: http://www.regus.com/locations/US/GA/Atlanta/GeorgiaAtlanta22Summit.htm?product=offices |
|
|
|
Thanks, i jus wish someone could write a program to keep track of the hashs, how long it took for a block, that would be cool. I would do it but have no idea how.
At the current difficulty of 1689k, it means you need (on average) to solve 1689k difficulty-1 shares to solve a block. You did 500k so far; statistically speaking you have a long way to go... |
|
|
|
|
Guys, there is no point in GPU-mining in VMs!
Alternative chains with GPU-based miners are compatible with standard (trusted) miners that don't need to be virtualized. This means you only need to run the (untrusted) alternative chain app in a VM, and expose its RPC port to the network where the physical miners are running...
|
|
|
|
Thanks - very revealing quote there. My reading of it is that he became aware of the GPU problem after the 'horse had already bolted' - and is thus appealing for a 'gentleman's agreement' for what he might have otherwise prevented in design from the outset.
Unlikely. You may have discovered the power of GPUs for the first time with Bitcoin; but when Bitcoin was being designed, the cryptographic community was already very well aware of their computing power for ALU-bound workloads like SHA-256 which mining is based on. I don't understand why you consider GPUs as being a "problem" presumably because the average user without a GPU farm cannot compete... The average user, by definition, owns an average PC that will run workloads at an average performance. It is inevitable that specialized hardware will appear and significantly outperforms him. Even if mining was done by an algorithm designed to be costly to implement in hardware (like Tenebrix using scrypt), this would cause miners to evolve toward specialized hardware like many-core server farms. |
|
|
|
Not only did Satoshi planned for an increasing amount of power being thrown at mining, but he did know that GPUs would exel at it, way before any GPU miner even existed, in December 2009: We should have a gentleman's agreement to postpone the GPU arms race as long as we can for the good of the network. It's much easer to get new users up to speed if they don't have to worry about GPU drivers and compatibility. It's nice how anyone with just a CPU can compete fairly equally right now.
|
|
|
|
for i in `seq 1 1000`; do bitcoind getnewaddress; done >addresses.txt
|
|
|
|
|
Update Friday 30, 07:08 UTC: I just bought 2 for myself. The order went through! 6 remaining in stock.
Update Friday 30, 07:15 UTC: now only 4 in stock... I will be online for about another hour. I will be offline between 08:00 and 16:00 UTC.
Update Friday 30, 07:50 UTC: still 4 in stock.
Update Friday 30, 08:01 UTC: still 4 in stock. I am going offline; I will return at 16:00 UTC.
|
|
|
|
|
This is a very unusual offer: just now, I stumbled upon a very high-end computer component on Amazon with a huge pricing error ($125 instead of $800-900 as on Newegg). I am not going to tell what it is except it is a PCIe card and NOT a graphics card (but something that is still common enough that Amazon and Newegg carry dozens/hundreds of different models of this type of device). The item condition is new. There are only 8 in stocks. I am definitely buying one for me, and one to resell.
Send me 1 BTC to get a bit more information, I will reveal the category the item belongs to: sound, network, raid, ssd, or firewire card.
Send me another 14 BTC and I will send you the URL to the item on amazon.com.
Email me or PM me. I will refund you if the pricing error is fixed, say within 5 minutes after the BTC payment receives 1 confirmation. This is a legitimate offer. Check my reputation on bitcoin-otc (see sig).
|
|
|
|
You mentioned 5830s so I picked that rigs as an example. 1.71 isn't even my most effecient rig.
You have a farm. Are you saying you can't pull off 1.71 Mhash/Joule on any of your systems?
 Err... I don't run inefficient 5830s. Who cares what the wiki says. The wiki is old and outdated.
That's what I said. "invalid data". I was implicitly asking for confirmation from anyone running 5830s. 1. Buy quality parts. 60% efficient power supplies are stupid.
2. Plug system into Killawatt meter.
3. Use latest mining software and optimize hashing parameters.
4. Overclock core speed and underclock memory speed.
5. Keep fans clean so nothing overheats.
There's no rocket science here. Just basic mining optimizations that any half-decent miner would do.
So we can deduct Tawsix is not doing any of this if he claims he is losing money. |
|
|
|
My 4x5830 rig draws 650 watts and outputs 1112 mhps which generates .64 btc and draws 15.6 kwh.
.15 for 9 hours and .08 for 15 hours is about .11 per kwh average per day.
Cost to generate btc is $2.59 per coin.
Your setup computes 1.71 Mhash/Joule. Although there is a lot of invalid data in https://en.bitcoin.it/wiki/Mining_hardware_comparison your claim is inconsistent with the wiki which puts the value anywhere between 1.3 and 1.6 Mhash/Joule. How did you measure 650W? Do you under/overclock the GPU or memory? Etc. |
|
|
|
Where do you live, Hawaii? Break-even is around $.20/kwh on a decent rig. The days of running a farm with electricity rates that high are over. Liquidate your hardware now.
Tawsix said below he pays $.15/kWh during the day and $.08/kWh during the night. My guess is that he made the mistake of building a farm mostly from 5830s which have terrible power efficiency. At $.15/kWh his cost of production on a 5830 is about $5.9/BTC, clearly losing money when the exchange rate is $4.8/BTC. **Something I didn't take into account when calculating power costs: I have a variable rate where 10am-7pm is charged at ~15 cents / kWh and 7pm-10am is charged at ~8 cents / kWh, so that drastically lowers operating costs**
Tawsix: I suggest you stop operating during the day to profit from lower night rates. |
|
|
|
Not sure if someone could get their hands on that many gpus.
Why? Tianhe-1A is made of 7168 GPUs. 21k high-end GPUs may take months to be provisioned by a manufacturer, but it is certainly within reach with adequate budget. |
|
|
|
|
Show Posts
I have done my best to educate you. This is my last post in this thread...
