Agreed.  It would make no sense for it to be a plastic flip chip and I don't think it is.  Just pointing out the chip photo is really low quality and hard to get any details but it is not what I would expect.  It looks very much like a PBGA flip chip designed for low wattage applications not a 4 die, giant 200W+ monster package with integrated heatspread and metal package lid for attaching a waterblock. 

For the later I would expect something which looks like this:
http://img.diytrade.com/cdimg/1297821/15922456/0/1286866175.jpg

or this:
http://i1-news.softpedia-static.com/images/news2/Intel-s-Upcoming-Core-i7-Mobile-CPU-to-Top-Out-at-1096-2.jpg

Simple version:  it is weird.  Hopefully they can take a couple of more photos from different angles, and maybe put the camera in macro mode.

They have control over what you call things?  Really?  If MtGox decided to NEVER switch their quotes from BTC to mBTC what exactly would the Bitcoin developers do?  What exactly would the foundation do?  Please give me a concrete example.   If I keep writing balances in BTC (or uBTC, or satoshis) are they going to have me arrested?  are they going to sue me? are they going to have someone kill me?  How exactly would they prevent a user from using a different valid denomination?

The protocol/blockchain/codebase doesn't even care about Bitcoins.  Everthing is recorded in integers as satoshis.  Everything else is just human concepts because humans don't work well with very large numbers.

Well it does look like plenty of packages I have seen just not one designed for high electrical/thermal output.

For example Bitfury chip. 


Avalon chip:


The lid is plastic but it is low wattage and the heat is conducted through the bottom of the chip to the PCB grounplane (and optionally to heatsink on opposite side of baord).

These photos (and granted they are really bad blurry photos with no angle view or size reference) look like a plastic package which simply can't be right not for 200W+.

That is a good question.  It looks like a complete package (die, heatspreader, substrate).  If it was only the die I would expect it to be bare silicon (has a rainbow sheen).  While I guess each die could be packaged independently and then all four attached to a substrate that doesn't make any damn sense.  So my first thought would be it is a complete package but it would appear to be too small, and not match expected characteristics at all.  I would be expecting a shiny metal lid, substrate which extends out from beyond the lid, and no writing on the package lid.   The lid is going to be the primary thermal transfer so it would be designed for high conductivity.

For example: KNC board. 
http://www.alchip.com/uploadfile/201311/20131105093923760.jpg
Big shiny in the middle is completed package (which also contains 4 dies like HF design although at lower throughput).


So based on the single photo alone it doesn't look like a completed package (4 dies + heatspreader/package lid + substrate) and it also doesn't look like a bare die either.  So

Some more and better photos (from side and bottom and with size reference) would help.

It is an interesting idea.  It essentially eliminates any "orphan cost" due to bandwidth related propogation delays.  As mentioned some complex tx can be computationally intensive but bandwidth & latency are likely are more critical resources.  Something would probably need to be done to handle significantly older blocks in a more efficient manner.  For example Bitcoin blockchain is ~270,000 blocks, if the padding was enforced for all block messages to bootstrap a new node would require ~270 GB, compared to ~12 GB actual so older blocks need to be handled without padding.

Still it is an interesting concept and if not used in Bitcoin it could be refined and used in altcoins.  This could be combined with another improvement, replacing tx with tx hashes in block message, to generate better results at reduced cost.

Block message format
magic # (4 bytes)
block size (4 bytes)
blockheader (80 bytes)
tx count (1 to 9 bytes)
transaction list (variable - average 600 bytes ea)

Proposed tx less block message format
magic # (4 bytes)
block size (4 bytes)
blockheader (80 bytes)
tx count (1 to 9 bytes)
transaction hash list (variable - 32 bytes ea)

The average tx size appears to be ~600 bytes, tx hash is 32 bytes so this reduces the new block message by >90%.  Now for bootstrapping nodes the first format is more useful but for up to date nodes they should have block txs in their memory pool.  It is also in a miners best interest to ensure their peers have all those tx to reduce the propogation time.  If a node is missing some tx they can simply request those tx by tx id (hash) from peers.  This method can be used by itself to reduce the orphan cost by itself or it could be combined with the concept in the OP to both reduce the bandwidth requirement and eliminate the additional tx orphan cost. 

One needs to consider how much padding would be required as there is no fixed relationship between size of all txs in a block and the size of all tx hashes in a block.  Since the goal is just uniformity some lower bound could be considered.   An average tx size of <300 bytes is dubious (would require a block of all single input, single output txs) so in additional to max tx size a max tx count limit could be enforced.  If the limit was 1MB and 3,000 tx this would make the max block message size 94 KB (4+4+80+9+3000*32).  Block message could be padding enforced to 100 KB (for current block size limit).

Block-txless message format
magic # (4 bytes)
block size (4 bytes)
blockheader (80 bytes)
tx count (1 to 9 bytes)
transaction hash list (variable - 32 bytes ea)
Randomized padding (100KB - rest of message size)

How would this work in practice.  Well lets look at a recent large block:
https://blockchain.info/block-index/444118/0000000000000002166ff15ec0ce6427f21c2f7ce55676d280b0677fe04c1f2a
Tx Count: 1368
Size with current block message: 882 KB
Size if padded to 1MB: 1024 KB (16% overhead compared to current)
Size using txless block message: 43KB
Size using padded txless block message: 100KB (89% reduction compared to current)


Pros:
For blocks over 100KB the new format even with padding is still smaller than the "full block" format without padding so there is no bandwidth costs to miners decrease.
Simplifies tx inclusion economics.
Can be implemented as a non forking change by creating a second new block message type and legacy nodes can still request block in older "full" format.
Doesn't increase on disk storage requirements.

Cons:
More complex broad propagation logic, older blocks need to be handled in legacy manner to avoid massively increasing bootstrap requirements.  
Hard enforcement at protocol level requires a hard fork (which may not be possible to obtain the consensus needed).
With a non-forking expansion, enforcement is only at the client level.  Miners could locate other miners and communicate directly in more efficient block message (i.e. block hash only with no padding) to gain advantage on other miners.

Not conclusively in all cases.   If two or more addresses are used in the same transaction then you can know they are both from the same wallet.  However if Bitcoin intentionally makes this kind of tracking difficult.  If you use a new addresss for each tx, send change to a new address, and don't reuse existing addresses while it may be possible to link some addresses together by analysising the blockchain it is impossible to link all of them together.  If someone cared enough they can make the job much harder but selecting inputs so they don't add additional information to the blockchain, using mixer services, and even used shared wallets (like exchanges) to kill the public trail.

As an example of killing the public trail:
If I deposit 1 input at a time to MtGox using a different address each time there is no way to link those txs together using the blockchain.  You would need a warrant to gain access to MtGox internal database.   I could then withdraw those balances (which will come from totally different random MtGox addresses) to individual addresses.  Making the amounts and number of withdrawals and deposits different and varying the frequency would make even probabilistic (guessing) analysis impossible.  Now imagine doing the same with multiple exchanges and other shared wallet services, cryptostocks, and even altcoins to ensure that the entire trail can't be reconstructed by a single entity even with private information.

Pools use the losing hashes as proof.  The pool is estimating your share of the block reward when a block is found.  If you contribute 1% of the losing hashes/tickets then (simplified) you will get 1% of a reward when a block is found.   Now the pool overall might be lucky or unlucky so it might take longer or shorter for the pool to get paid but by counting your tickets vs entire pools tickets the pool can ensure a) that you are actually working, and b) what "share" you should get.   Depending on the pool the "confirmed" reward is likely your share of blocks which have already been found but the pool is waiting for it to mature.  The "unconfirmed" reward is your share of the current block miners are looking for a solution to.  If the pool is PPS then the pool is simply paying you a flat fee per losing ticket.  The pool is taking all the risk and when a block is found faster they get more than they payout and when a block is found slower they payout more than they get.  This is why the fee is generally higher for PPS.

To use the lottery ticket analogy imagine you and your friends make a lottery pool you all buy lottery tickets but you can't be together for the drawing, you don't even know when you will get a winner.  So you all buy tickets (some can buy more, some can buy less) and everyone saves their losing tickets.  Now the losing tickets are worthless but they are proof you helped the pool.  When someone wins the lottery everyone comes together and everyone's losing tickets are counted.   If since the last winner you bought 120 tickets and the combined total for everyone was 12,000 tickets then you would get 1% of the jackpot regardless of who actually bought the jackpot ticket.   Note: don't do this in real life without cryptography this is a very bad setup and very easy for the winner to just walk away with the winning ticket or broke players to grab old losing tickets from the trash to pad their stats.   In mining however the use of cryptography means you can't cheat, but the general concept of using losing tickets/hashes as proof of contributing still applies.

Well those are addresses not wallets.  Unless you intentionally consolidate coins a wallet will contain a large number of addresses.

So for example someone had a wallet with 1,000 active addresses and the average balance per address was 10 BTC they wouldn't be even on the top 100,000 address list but they would still have 10,000 BTC.  Another thing to consider is that most likely when a single large early adopter sells off a large amount of BTC it is being bought up by multiple parties so distribution to a larger base occurs.

As pointed out above most wallets use a new address for each tx and don't reuse addresses, and send all change to a new address so unless you intentionally "send coins to yourself" to consolidate it you won't end up with a few large value addresses.  The main purpose for those massive addresses is offline storage.

Say you are MtGox and users have deposited 500,000 BTC.  You know that on your highest volume day the net outflows (BTC withdrawn - BTC deposited) is 10,000 BTC it makes absolutely no sense to keep 500,000 BTC online where they can be stolen.  You can move 400,000+ BTC offline likely in single large tx and you may not need to move them to an online (hot) wallet for months, maybe years.  If the exchange remains popular and growing you may never need to move those coins online ever again. 

There are a lot of entities which act as a bailor (google it) for other people's coins.   Exchanges, the Bitcoin trust, Bitcoin ETF, Bitpay, and yes the SilkRoad (now in the hands of the DOJ).  Those entities don't "own" the coins they are holding them on behalf of someone else.  Now they certainly can steal them (and people should be aware of the counterparty risk) but for example if one (or dozens) of those top 500 addresses is MtGox cold storage address it doesn't represent the wealth of a single person (or even single company) it represents the entrusted wealth of thousands maybe tens of thousands of users.

Hmm that is a good point.  I hadn't considered that but looking both at USC code and NMC code I believe you are right it was an incorrect assumption on my part.  Since all SHA-256 coins use Bitcoin as parent I assumed that was encoded but it looks like it was not.  Would be interesting way to gain hashpower from many chains.   Obviously LTC is the biggest bang for the buck (10% of LTC network is worth a lot more than anyone else) but it may it does mean the coin isn't limited to the success of the parent as it can switch to whatever parent(s) are viable at the current time.  Thanks you helped me learn something today.

Another interesting idea (and it would be a little more complex probably requiring two different difficulty values) would be to create a coin which can use either hashing algorithm and support merge mining against chains with either algorithm.

Yes.  That is what testnet is for.  You are running testnet to conduct your own research before "fixing" Bitcoin.

Like I said the limit will be raised.  It is just a matter of how, when, and to what level.   Still if the limit was 2MB right now we still wouldn't have 1MB blocks.  Miners are chosing to self enforce a lower limit.

Actually even that is simplistic because most miners are enforcing tx rules not a preset block size.  The intersection of current tx volume and the rules set by miners is producing blocks <250KB on average.  Going from 1MB to 2MB or 20MB isn't going to change that tx selection behavior.  Most waiting tx (if we look at seen longer than 1 block prior) are free txs.  Miners are willing to make larger blocks but not larger blocks full of free txs.

PayPal will rubber stamp any dispute in favor of buyer.   Search the forum for countless examples until you get bored (and even then you probably haven't even seen 1% of them).  They won't even look at any proof you may think you have.

What is the safest way to turn $2,000 into $4,000 in six months?

"safe" and "double money in six month" are generally mutually exclusive.  If it was safe, everyone would do it and the return would be lower.  The fact that the potential return is high is because it has risk.

This.

It may seem nitpicky but understanding this concept will save you a lot of confusion in the future. It will also help you understand the whys.  Why only you can spend your coins.  Why" you don't need to be online to receive coins.  Why it is not possible to make fake Bitcoins or fake a transactions.

Your wallet has no coins.   That is right it doesn't have a single coin in it.  Online offline, QT client, multibit, eWallet I don't care no wallet has any coins.

Copies of the "coins" (unspent outputs from prior txs available for spending), all 12,028,275 as of this post are on every node in the network.  Right now, "your coins" are on over a hundred thousands copies of the blockchain, located on strangers computers all over the globe.

So if you wallet doesn't contain coins, what does it contain?  Your wallet has a set of private keys which let you (and only you) spend coins sent to you (or technically to addresses for which you have the matching private key).  Your wallet (any wallet) never needs to be online to "receive" coins, because nothing is sent directly to you.   When "sending coins", the sender creates a message (transaction) which transfers ownership of "coins" from addresses he control (he has matching private key) to addresses you control (private keys are in your wallet)*.  The message is relayed from node to node who all independently verify it and eventually a miner puts it into a block to make it permanent.

When your client (the wallet program) shows a balance of "10 BTC" what is really means is the client scanned the blockchain matching all unspent outputs to addresses which correspond to private keys in the wallet and found one or more unspent output that when totalled are worth "10 BTC".  You "have" 10 BTC because you have the ability to send/transfer/spend 10 BTC.    

Since coins are on every node in the network the only thing that makes them "yours" if the fact that you (and only you) have the private key to spend them.  In Bitcoin ownership for all practical purposes is control of the private keys to addresses which have unspent outputs.
If you lose your wallet = nobody has private keys = the coins will always exist but nobody will be able to spend them.
If an attacker steals your wallet = attack has a duplicate copy of the private keys = attacker can transfer the coins to addresses only he has the private keys for.


* Note that still isn't technically accurate because Bitcoin works on a concept of inputs and outputs, not value or balances at an address.  Still this is a technical distinction which isn't really necessary to understand Bitcoin at the user level.  Just understand the rabbit hole goes deep.  When you think you know everything about Bitcoin ... you don't.

This is bitcointalk forum and last time I checked Bitcoin only uses a single hashing algorithm.  The moderators created an altcoin subform for off topic threads.

I was thinking this the other day.  The split made sense when ASICs were theoretical and GPU were mainstream.  Today nobody mines Bitcoins with anything other than ASICs and it seems there is some cross posting and "incorrect" posting which means people end up reading both forums anyways.

Ask your question.  Not an (incorrect) statement phrased as a question.  Just ask the question which is underneath all that.  I don't want to try to decode what I think you might be meaning to ask.

There is no progress so there is nothing to lose or nothing to resume.

Each hash is like a lottery ticket.   It either solves the block or it is a loser.   Buying and losing with 1000 lottery tickets doesn't make you "closer" to winning the lottery.   Hashing a billion hashes which don't solve the block doesn't make you closer to solving a block.

Nobody is making 1MB blocks.  Nobody.  Not a single block in the history of Bitcoin is 1MB.  So the "limit" isn't a limit.  Miners are choosing their own parameters which result in blocks less than 1 MB.

It would be like the fastest car in the world is 180 mph and there is too much traffic so the government decides to raise the speed limit from 500 mph to 2,000 mph think that is going to have any material change.   The limit will be raised eventually I have no doubt but right now the constraint on tx volume isn't the 1 MB limit.  That is pretty obvious when there are no 1 MB blocks.  The constraint is on the economics of mining.   Eligus for example makes some of the largest blocks on the network.  Routinely over 500 KB but they also include no free transactions.  Eligus couldn't make a 1MB block right this second even if they WANTED TO because there aren't 1MB worth of paying tx waiting for a block.  So how would raising the limit to 2MB, 5MB, 10MB change anything to that equation?

Case in point here is a recent Eligus block.
https://blockchain.info/block-index/444092/00000000000000029fd11f8e23b450749807f78ab4aa789b764cd10ea7062e59
780KB
1280 txs. 

It couldn't be any larger because it includes 100% of the tx which met Eligus inclusion requirements. 

Miners aren't colluding but they do heavily limit the amount of space the devote to free txs.  Some pools like Eligus make the LARGEST blocks but include zero (yes zero) free txs.   Excluding brand new tx, ones with unconfirmed outputs, and double spends/problems at any given time 90% of the memory pool is free txs.

The fact that miners haven't gone cold turkey and universally killed all free txs doesn't mean it is a reliable method of making a payment.  The free tx volume is growing and the amount of free txs in a block are declining the result of those two is the backlog everyone complains about.   It is silly to think miners are going to change.  It makes no sense for them to do so.  Many will include some free tx because it provides a release valve on the network but while blocks get bigger I wouldn't expect the amount of free tx in blocks to get bigger.  If you want timely processing include a fee it is really that simple.  If you don't then it could be days, weeks, potentially months before your tx is processed.  You are asking for charity and charity isn't always reliable.

Except that ISN'T the problem.   If miners can make a positive return by producing larger blocks ... they will.  They want money, more money is always better.   However tonight you could flip the network to 1 GB blocks and ACTUAL block sizes aren't going to change at all.

Miners actually are including most paying txs.  Take a look at the memory pool, remove tx seen after the last block and 90%+ of the remaining tx are:
* no fee txs.
* txs with unconfirmed outputs.
* double spends or other tx problems.

Implementing child pays parent will improve the second category, the third category probably should just be excluded.  That leaves essentially free txs.   Miners aren't going to produce 20 GB blocks of free txs just because users want something for nothing.  That is never going to happen so as the correct titles says "Blocks are NOT full.  What is the plan?".


The good news is there is something which can be done to make blocks larger and reduce confirmation delays:
1) The default bitcoind has a rule where fees double as blocks get larger.  It looks like most major pools have stripped that out otherwise we wouldn't see blocks >500 KB however that rule should probably go.  It no longer really serves any purpose.  The nice thing is it is a client side change so it requires no protocol change or fork.

2) Education.  Until recently a company as big and old as MtGox was creating free txs.  For something as timely as exchange cashouts that is just stupid.  Sorry it is.  They should know better.  If you want to send your friend Bob some coins and want to be cheap that is one thing but major commercial enterprises should really be favoring reliability over trying to save pennies.

3) Child pays parent.  Currently the way bitcoind prioritizes txs it does not include paying tx with unconfirmed outputs in the next block.  So someone sends you coins with no fee, or possibly a bunch of dust spam and you try to resend them and include a fee and it looks like miners are screwing you over.   The tx selection algorithm needs to be improved so if tx B has as an input an output for tx A and tx A has no fee and is unconfirmed but tx B has a fee the miners will include BOTH A & B in the block.  This would also allow users to fix stuck txs and allow merchants to get confirmations on payments faster by respending them.

3) Improve block message format.  Currently all block messages are the same old blocks back to the genesis block and the newest found block are transmitted as header + list of txs.  For new blocks, nodes that are up to date likely already have most (and probably all) txs so a simple change to create a block header + tx hash message would reduce the bandwidth requires by ~90%.  A 1Mb "header + hash only" block message would be smaller than a 100 KB full tx block message is now.