Correct.  An block with an invalid tx is an invalid block and a complete waste of the massive amount of work necessary to solve it. An invalid block would be instantly rejected by all other nodes and will never be part of the longest chain.

However miners actually validate txs as soon as they receive them.  Actually ALL nodes validate tx as soon as they receive them.  Don't use the word "confirm" to mean validate as "confirm" generally is used to indicate a tx that is included in a solved block which has been added to the blockchain and is part of the longest chain.
 
So a node (any node) receives a tx from its peer.  If it is invalid the node discards it.  If it is valid it adds it to the memory pool (list of unconfirmed tx) and then relays it to all its peers.  Those peers do the same thing (including the independent verification of the tx).  Now if the node is also a miner* it will take some tx from the memory pool (all of which are already valid) assemble them into a merkle tree and construct a block header from that.   If the block is solved the miner will broadcast the block to other nodes.

When a node receives a new block it validate the block including:
1) all tx in the block are valid
b) the merkle tree and merkle tree root is valid
3) all the information in the block header is valid
4) the block hash meets the difficulty target

Once the node confirms the block is valid it will add the block to the blockchain AND remove the tx included in the block from the memory pool.  The node will then relay the block to all of its peers which do the same thing.  If the block is ever orphaned the node will add all tx that were in the block back to its memory pool.

Thus all nodes have two "lists"
a) the memory pool = list of valid unconfirmed tx not yet included in a block.
b) the blockchain = linked list of blocks and the confirmed tx they contain.

All nodes follow this sequence (for both txs and blocks)
receive -> validate -> store/update -> relay

700W AC is 630W DC.  Power supplies are rating on DC load.  630W load on 850W supply is <80%.

I do and I would like answers.

Thanks taco, hopefully you get a quick response.

I PMed HashFast about MPP "formula" and delivery timeline.

No different than shorting anything else.  You can't short a stock without someone lending shares.  Usually (not always but usually) you don't lend your shares (or Bitcoins) to the counterparty you lend them to the broker or exchange who lends them to the person going short.  Granted this doesn't eliminate the counterparty risk but it does allow shorting to exist if both parties trust the broker or exchange even if they don't trust each other.

There is no "allowed" in Bitcoin.

People do short Bitcoins, people will continue to short Bitcoins.   There is absolutely nothing you could to prevent people from shorting Bitcoins.

Welcome to the decentralized future.

No.  

ScriptSig
The ScriptSig is the digital signature created by the SENDERS private key.  In Transaction A the ScriptSig is a digital signature created by signing a hash of the simplified tx* with Alice's private key.   It also contains a copy of Alice's public key so the signature can be verified (because Satoshi likely didn't know about ECDSA public key recovery).

The ScriptSig (one per input) is used to validate the transaction.   This is how we know Alice (well someone who has access to Alice's private key), not Bob created the transaction.  In your diagram, anyone could steal Alice's coins by simply creating a tx sending them to their address (pubkeyhash).

scriptPubKey
You have it written the scriptPubKey is a hash of the ScriptPubKey.  In actuality in most tx (https://en.bitcoin.it/wiki/Transactions#Pay-to-PubkeyHash) we are paying to the PubKeyHash so the PubKey isn't in the output.  The PubKeyHash is.  The PubKey is included in the input of a subsequent tx.

Simple version:
Input:  Contains signature created by sender's private key AND copy of sender's PubKey
Output:  Contains the hash of the public key (PubKeyHash).

Most people use addresses but when you tell your client to send x BTC to Bitcoin address 1KtshSbdFmGBaBZsYxi9ZUv4EqRnwce7tb the client reverses the address to the PubKeyHash and that is used in the tx output.  This is why we used PubKeyHash in the output not the PubKey because the PubKeyHash can be reversed from an address however the PubKey can't be derived from the PubKeyHash.  However for validating inputs we can easily hash the PubKey to get the PubKeyHash and ensure it matches the designated prior tx output.
 



* Remember a tx can have multiple inputs and each input is signed by the private key for that input so a simplified version of the tx is constructed including that input and the outputs which is hashed and signed.

PSU are rated on DC load not AC.  With efficiency around 90% 850W DC would be like 935W AC at the wall.  Nobody anywhere has reported power usage anywhere close to that.   You can only push so much power into the unit.  The chip can only handle so much current, and even if it could use more the DC regulators have a finite capacity (4 @ 40A ea per board). 

To push the clocks higher you need more power you don't need 100% to 200% additional power.  It is like saying I can push 1,000 into a GPU and make it go faster

It depends on how much of a discount you get and how likely the risk of failure was.

When new HD 6990s were >$700 I bought 40 used 5970s for $250 to $400 ea.  2 were DOA which I disputed w/ ebay and returned for refund.  Of the other 38, two of them died over the next 18 months of mining.  I probably saved >$10,000 compared to new.

ASICS are used to find a nonce which gives the block the proper hash.  You do this once per block which may contain an arbitrary (well currently capped at ~4000) number of transactions.  The actual block header creation is computationally "cheap".  A single CPU core can validate about 15,000 tps.

That is correct and fabrication takes usually 60 days, 45 days is possible for small high cost "rocket runs".  Wafer cutting, testing, and packaging is easily another 10 days.  So count on 55-70 days for chips.

Still Dec/Jan is going to be "interesting".

At 50% load the PSU will be cooler and thus more efficient so you actually are supporting the reverse conclusion.  However then again the difference is marginal.   BTW JohnyGuru does extended testing in a hot box to control the ambient and simulate actual working conditions.

Yup it makes sense now.  I feel stupid (but I blame it on a lack of caffeine as part of a balanced breakfast) .

1) They have never provided hard sales figures.
2) Why would any ASIC company lie to overstate pre-sales UPWARDS? 

Imagine the CEO of KNC came out today and said "we have already sold 5 PH/s worth of rigs for November and still have another 5 PH/s available"  What do you think that would do to future sales?  What do you think that would do to refunds?  

If anything, all ASIC vendors have been rather coy about how much capacity they have sold because they ALL know the more capacity sold the less they are going to be able to charge for "the next rig".  With delivered units customers can see it in the hashrate but for undelivered units no company wants customers to know the "truth" if the truth means they won't be able to sell more of those rigs they are continually building.

TL/DR: the best conspiracy theories are ones which at least have a glimmer of rational thought.

I am not sure.  I have been analyzing blocks, compared to the memory pool and I have seen lower tx fee transactions be included along with free transactions while higher or same valued tx (sometimes older) be not included. 

My guess is that at least one miner (miner in this case is the person controlling the block construction) likely has a non-optimal tx selection setup.  My guess is they have a hard target of say 100KB  and reserve some of it (say 20KB) for free tx.  This results in the pool leaving paying tx. 

Honestly the latency and thus orphan effect on the difference between a 300KB block and 100KB block is negligible for a well connected miner (once again miner is the person creating and publishing blocks) it may simply be a configuration "issue".

Now if blocks were nothing but 100% paying tx going from highest to lowest then I would agree you probably are right.   The good news is the block subsidy will continue to fall this will remove the distortion from the market over time.

http://www.corsair.com/en/blog/80-plus-platinum-what-does-it-mean-and-what-is-the-benefit-to-me

At least for corsair high end PSUs and other high end PSUs the bets eff spot is still 50%, even if its only 1-2%
[/quote]

Thanks for agreeing with me.  Did you read what you quoted.   ~Yes 50% is the peak efficiency but it isn't like a 1250W PSU has the same cost as a 850W one.  If choosing an oversized PSU costs you $100 upfront and saves you $5 per year it doesn't make it "super win".  Not saying it is "bad" but it isn't "bad" to aim for something more economical either.   Hint: KNC uses 850W PSUs.  What really matters is lifecycle cost.  Lifetime hardware cost + lifetime energy cost + lifetime cooling cost.   

As a though excercise say KNC sorted their chips and took the highest efficiency ones and packaged them into a "Super Jupiter".  The Super Jupiter would get 2% higher hashrate and use 2% less electricity however it costs 100% more than a "normal Jupiter".  Would you buy one?  Me I probably would just buy two normal Jupiters and get double the hashrate for marginally higher energy cost.

People have asked, estimated and simulated.   Still nobody is saying max out blocks.   However right now the average block is 200KB with a large portion being under 100KB. An average block size of just 300KB would clear 90% of the backlog.  Also 50KB per transaction?  Ouch.  No the average tx is <1KB.  Of course fees are per kb so 0.1 mBTC on 50 1KB txs is no different than 5 mBTC fee on a single 50 KB tx.  Lastly on your math 1 MB = 1024KB so that is only ~20 tx of 50 KB ea not 2,000.

Hopefully pool operator are also forward thinking.  Many pools include some free txs despite them adding 0% more revenue.   Remember if Bitcoin collapsed or adoption falls and there is lots of negative press about it being dysfunctional and impossible to use as a payment system then the BTC the miners are making are worth less.   Miners benefit by keeping the tx system "healthy".   The fact that many pools are leaving PAYING tx likely means the issue is a configuration one not an intended policy.  One recent block included 0.02 BTC worth of paying tx, 80 free tx and then behind 0.08 BTC worth of paying tx.   That doesn't make economic sense for any miner so either pool operators are dumb or tx selection configuration is non-optimal.

  

Nope.  He is right the curve tends to peak around 50% (but it is still foolish to aim for that).  You can check the official curves here.  http://www.plugloadsolutions.com/80pluspowersupplies.aspx

Also I think if you recheck those reviews you will find they don't show a peak at 80%.

The point is that the curves today are very flat there is no reason super-duper oversizing a PSU (and pay $100 to $150 more) to gain 1% to 2% higher efficiency.  See post above for more.

Of course the "has to be 50%" myth will never die.  At one time it did make sense because the efficiency at 50% load might be 85% and the efficiency at 80% load was a horrible 68% but those days haven't existed for more than a decade.

At one time the efficiency curve was very "curvy" but those days have been gone for a long time.   Today the efficiency curve is very flat the difference between 50% load and 80% load is usually 1% to 2%. 

So buying a super sized power supply to run it at 50% load would save you a whole 1% * 600W * 24 * 365 / 1000 = 52 kWh.  At $0.10 electrical rate the savings would be a staggering $5.20 a year.  Now if you spend $100 more for this larger "have to run at 50% load because some article in 1998 said that" power supply your break even point is roughly 18 years of continual usage.