Any brokerage in the world?

Yeah "mystery" miner this applies to you to.  No more 700 bitcoins per day unless you upgrade.

No the # of confirmations increases the difficulty of an attacker getting lucky.

Like trying to flipping a coin 6 times and getting 6 heads in a row is harder than getting 1 heads in a row.

Regardless of block times if you want "6 confirms" worth of security you need to wait for 6 confirms.

The larger the % of hashing power an attack may have the more confirms you need to have a given % chance (say 99.99%) that he can't reverse a transaction.  Obviously once attacker has 51% hashing power no amount of confirms provide security.  Satoshi lays out the math at the end of his paper.

An update:
Had a minor leak at the radiator where the inlet pipe was knocked out of round.     Removed existing fitting, sweated on a 90 deg connector (which I wanted to use anyways, if you got to resweat the pipe at least make it an upgrade).  Was water tight for 12 hours+.

My Primoflex Pro LRT tubing (ID: 7/16 OD: 5/8) arrived.  A perfect fit for 1/2" PEX connectors.  Nice and flexible.  I updated the fitting on the rig to 1/2", attached the tubing put the inline no leak quick disconnect connectors and ran the loop to the manifold.

Had a minor leak when cutting water on.  The 1/2" barbs I bought don't fit on the "metal side" of the waterblock (they fit fine on the other end).    They threads are too long and they bottom out before compressing the o ring completely.  Luckily I had a pair of 1/2" barbs hanging around.   BTW large amounts of shop towels underneath all fittings made initial water turn on less scary.  Used hair dryer to remove any water (I didn't see any but I am paranoid).  Leak tested it for 12 hours.  Looks good.

Powered up the rig this morning.


Clocks are 830/150 at stock voltage.  (Most of cards were stable @ 870 but I decided to start low).
I am planning on eventually overvolting them slightly but that requires a bios flash.  I think 900/150 @ 1.125V should be possible which should give me 3.2 GH/s per rig.

Ambient is about 33C.  I have the garage closed with no AC to simulate hotter ambient temps of this summer.  I don't have my radiator fan yet so this is using a 14" desktop fan pushing minimal air through radiator.

Looking good so far.

Whats next:
Hopefully this weekend I can get the second rig connected to the loop.  Also want to mount the manifold to project plywood and start planning the PEX runs.  I also need to go grab the server rack I bought off a friend.   The next phase involves 20 danger den waterblocks (sound a bulk discount of $99 per block), 5 more server chassis, 50ft of tubing, and some fittings.

If you want to avoid the second one there is a submit stale = true option available in the config file.

If the share is genuinely stale though that will simply increase the stale count on the pool server.  If the share is valid it will prevent cgminer from proactively killing it.

Why?  Compiling the kernel takes time and resources.  It makes the first start much slower.

That is the entire point of saving a bin file.

1) cgminer looks to see if bin files exists (binary version of OpenCL kernel)
2a) if no bin file exists it compiles the open CL kernel using CURRENTLY INSTALLED SDK and saves a copy as bin file
2b) if bin file exists then cgminer saves time and resources and loads that bin file
3) compiled binary (bin file) is loaded onto the GPU
4) execution begins

The 2a & 2b means if you upgrade sdk but DON'T delete the bin files you will run cgminer used kernel compiled on the SDK at the time of first start.  If later you install a new copy of cgminer (which has no precompiled bin files) then and only then will the new SDK be used.

ckolivas could make cgminer compile on the fly on each startup and it likely would reduce confusion because as soon as you upgraded SDK and restarted cgminer you would see performance drop and people would stop blaming later version of cgminer for the drop. Still that change would only help the uninformed be less clueless and would slow start times for everyone else.

That is a bold prediction.  The most powerful GPU will be the most powerful GPU.

There is.  What chart are you looking at?  Maybe your monitor is upside down?

Not this way.

The people give the authority to investigate crimes to the Police.  They still must abide by due process.  An entity simply making themselves final arbiter without due process is tyranny. 

I tried to buy GirlScout cookies with Bitcoins but they wouldn't take them.  Have I been scammed? 

Anyways the pool pie chart could be expanded.  Would like to see breakdown over last 7 days, 30 days, 90 days, etc.

Also an option to show all "shares" in pool breakdown would be nice.  If xyz pool has 0.25% I would like to see an expanded version of chart showing that (so only unknown remains unidentified).

Lastly not sure if this is possible but some line chart showing say trailing 7 day average of % of each pool so we could see trends.  Like as p2pool grew where did that hashing power come from?

Even with CUDA it is unlikely it would come close to a 7970 and likely not even a 7950.

AMD has two very valuable instructions which allow it to save a large number of clock cycles each round.  500 series NVIDIA cards lake any equivelent.  Since these instructions are useful in many forms of encryption one would expect we would see that or have it mentioned by NVIDIA or have it reflected in intop benchmarks.

You do  know Mt.Gox has a trade API right?  

https://en.bitcoin.it/wiki/MtGox/API/HTTP/v1#Submit_an_order

nope.  single, double and float refer to floating point math.  NVidia has always had great floating point processing power.  Of course it is completely useless for hashing.  You want something dealing with integers (whole numbers).

https://bitcointalk.org/index.php?topic=69105.msg811192#msg811192

Really?

Hmmm

double or single precision refers to floating point math.   I think there is a toms hardware article which has some OpenCL integer math comparison and the 680 is totally outgunned by the 7970.  It is even marginally out gunned by the 7950.

True miners would need to notice that B->C depends on A->B but as subsidies decline and tx fees become more important it is a useful way to move the tx cost to the receiver.  Receiver can wait and hope it is included eventually (which maybe the want to do if the payment isn't pressing) or pay a premium fee to get it in the next block. 

What?

The RECEIVER would build upon the unconfirmed transaction.

i.e. you (being cheap) send me 5 BTC from Address A (owned by you) to Address B (owned by me).  No fee was included so the transaction isn't being picked up by miners.  I take the unconfirmed B and send it to C (another address owned by me).  I include a fee of 0.10 BTC.

A smart miner would see B->C wanting the fees see it is dependent on A->B and include both in the next block.  A really awesome "confirmation booster".   A solid +1 to Steve.  A very nice way around senders paying for tx fees.


Um that is exactly what he proposed except there is no need for a special tx.  Simply a tx with a fee that uses as an input the output of an unconfirmed tx w/ no fee.

I mean that sucks but on the other hand I got to say awesome to the malware writer.  Get the user to send coins to the wrong address.  No need to keylog, hack the client, look for wallet.dat, spoof RPC, etc.  Just get the user to send you money.

Agreed.  Lets go pricing war! Lets go!