Also for information, time_t is a 64-bit field on current boxes, so the bitcoin header is not using a "standard" unix time_t anyway, to the extent that such a thing exists.  I don't think time_t has been a 32-bit value anywhere important since 1995. 

Anyway, we're looking at 2106 (unix epoch exceeds unsigned 32-bit value) not 2038 (unix epoch exceeds signed 32-bit value) before the bitcoin protocol becomes undefined. 

I think that this is the winning proposition.  With existing ASICs we can't change the length of the header without making them fail to produce standard SHA256, but we can change its structure to include a hash of the things we can't add (and the things we had to displace to make room for the hash, sigh).   You're right that we have to use the version field as intended; otherwise current clients will produce unimaginable confusion. 

Well, yes but... so?  That's kind of my point.  It's more space efficient, but it still needs a billion dollars worth of security.  If you pay for the same space you use to secure a six-dollar SatoshiDice transaction, you won't get a billion dollars worth of security.  

On the contrary, basing the amount of security you're willing to pay for on anything other than the value you need to secure is what is not anchored in the reality of the situation.  It was an easy mistake to make in 1998 because Satoshi was not thinking about the concentrating effects of special-purpose security hardware.  Now that our security is 99%+ provided by such hardware, we have to structure our payment to provide for that, rather than providing for the incidental storage and bandwidth costs.  Storage and bandwidth are not where our security is coming from.

The choices are:

General inflation proportional to the amount of the money supply would impose the cost of security on all holders, regardless of how often or in what amount they make transactions.

Transaction fees proportional to the amount of the individual transactions would impose the cost of security on those actually making the most and the largest transactions.  

The "right answer" is probably some mix of the two.  But it certainly is not block subsidies tapering off to zero while transaction fees remain unrelated to the amount of security we need to purchase for them.

As DeathAndTaxes indicates, and for the same reasons both you and he have mentioned, that's almost certainly the case.  So it turns out that the difficulty field can be moved if needed.  

But I'm still concerned about the (virtual) 'length' field at offset 56 in the last block.  If we use existing ASICs, I'm pretty sure they'll continue to hash based on an image of the last block that ends with the length of the current bitcoin header rather than the length of the revised header.  The result will be that bitcoin hashing via ASICs, while still possible, would be according to a variant away from standard SHA256, and various software tools that use standard SHA256 as a building block would need modifications to account for the difference.  

In fact, the first of these would be bitcoind itself, where the SHA256 calls that it sources from SSL would spit out a different hash resulting in an 'invalid block' message.  It would need to implement a "SHA256D_Variant" to avoid an (additional) immediate hard fork.

Obviously we're talking about a hard fork change anyway...

Okay...  What the hardware ASICs get is a hash representing previous 64-byte blocks, and the last block.   In standard SHA256, the last 8 bytes of the last block are used to append a length, so the last block can be at most 56 bytes long.  If it's longer, the standard SHA256 algorithm appends another 64-byte block (padded with more zeros) to hold the length field. 

But existing ASICs are depending heavily on the particular structure of the last block, so there are rules about the last block which you can't change while maintaining compatibility with existing ASICs.

The timestamp at offset 4 (bytes 4 - 7 in the last block) either can't move, or must become an added nonce field, because existing hardware is modifying that location in order to extend the nonce range already, resulting in timestamps on mined blocks that are inaccurate by up to 256 seconds.  Nothing else (except another nonce field) could be modified in that way without destroying the validity of the block. 

The difficulty field at offset 8 (bytes 8 - 12 in the last block) can't move because that's the location that existing ASICs read in order to find out whether the hashes they're coming up with are low enough to win or not.

The nonce field at offset 12 (bytes 12 - 16 in the last block) can't move because ASICs are testing images of the blocks with all possible values there, and will cough out the value to overwrite that location with.

Important values that the hash has to include cannot be located after offset 12 in  the last block because existing ASICs are only reading the first 12 bytes of the last block before they start work to determine what to overwrite bytes 12-16 with (the rest is assumed to be zero-padded out to offset 56, and followed with a constant length field).

Your point that the nonce field at offset 12 could compatibly be an 8 or 16-byte field instead of a 4-byte field is a good one.  Future generations of ASICs could use that, as you say, to support faster hashing without messing with the timestamp field.

But your answer to my original question is that the second 48 bytes of the second block could be used to hold data.  For example, if we wanted to put the (32 byte) Merkle root of the current UTXO set in the header, we could put it there. 

Also, now I have a second question.  Since current ASICs presume they are working on the second=last block, won't they be putting the length of the current rather than the revised block header in at offset 56?  And therefore won't the results deviate from "real" SHA256 when they are used on the third=last block?

For what it's worth, I've been looking at the question of mining (and premines, etc) a bit differently.

In my estimation, the block subsidies and transaction fees are what the investors (or holders) pay the miners to keep the blockchain secure.  If these payments get too low relative to the value secured, then the blockchain becomes insecure and you get 51% attacks etc.

In that light the "standard" model we've been pursuing of block subsidies halving as the value secured grows larger seems dangerous.  As the value we're trying to secure grows larger, we intend to pay less for security.  We shall, in that event, GET less security. I've been watching alt chains with faster halving periods dying like flies, and I can tell you for sure that this is something that's real.

That brings us to transaction fees.  We are paying to secure value, and we are not paying transaction fees relative to value.  We are paying transaction fees relative to space.  Space - which is to say hard drive sectors and network bandwidth - is not what secures our value; what secures our value is a monetary hardware investment in ASICs and powerplants.  Which we need in proportion to the value we're trying to secure.  And which we will not get in proportion to the value we're trying to secure by paying for space instead.

My conclusion is that if we want to keep the network at zero inflation and pay for security out of  transaction fees, we should be paying transaction fees relative to the value of each transaction.  And if we want to keep the network going without transaction fees that cost a percentage of the transaction, we should accept an inflationary model where each year the block rewards are, eg, 5% larger than they were the previous year.  So, in the long run that approaches 5% inflation. 

Both of these options are not popular with the current crop of BTC holders.

Sergio Lerner has made a proposal on his blog for a redesign of the bitcoin block header. 

http://bitslog.wordpress.com/2014/03/18/the-re-design-of-the-bitcoin-block-header/

The intent is to increase security somewhat, (owing to "terribly technical details about the way the hashing algo works") allowing space for some additional information, while leaving the structure compatible with the existing investment in ASICs etc.

I'm interested in this question and would like to hear what people think on reviewing it.

One thing I do not understand is why the last 48 bytes of the second block of his proposed redesign have to remain with "zero, do not use." 

Bear in mind that not everyone lives under the same government. 

In the US, cryptocurrencies are "commodities" which makes tax issues a bit difficult.

If you're going to try to use it like currency in the US (pay for pizza, etc), you need wallet software that keeps track of your capital gains/capital losses as you go, so you can file accurate taxes.  As far as I know, nobody has set to work on developing it - so there's some development that bitcoin (or any alt that's for american use, really) could benefit from.

In Germany and many EU states, cryptocurrencies are considered "privately issued currencies" and subject to private exchange rules and laws. 

In Japan, they are considered to be "Foreign currencies" and subject to forex rules.

In China, banks and currency dealers are forbidden from handling them but individuals are not; otherwise, individuals are responsible for conforming to currency control laws whose interpretation varies from day to day and official to official (and, at least according to some, depending on the size of the bribe paid to that official).

I'll go have a look at 'em. 

But it may be a day before I get to it; I've been working on this for the last three hours at this point and I'm tired of it for right now. 

Today I went trolling through many pages of old altcoin announcements, looking for alts that had been launched.  I tried to avoid putting things on the list that were just jokes, or where the launch didn't actually happen, or those which were just preannouncements.  Then I went and filtered out those that have a current market cap indicating not-dead, then I added the ones that weren't already on the list.  This probably amounted to 40 to 60 altcoins new to the list, which were quietly sitting there dead when I started keeping track.

There is a significant chance I made mistakes.  People should check the work and see if there's anything false, or anything listed twice, or etc. 

I've been trying to track the deaths of altcoins;  Not so much to hasten them along as just putting up a memorial so they won't be forgotten.  The list of "dead" alts I know about is at:  

https://bitcointalk.org/index.php?topic=588413.0

There's room for debate; some of those blockchains are still running, but with microscopic market cap.  Others could be revived at some future moment.  And I'm sure there are dozens or hundreds that I don't even know about which could be added to the list.

But in general, these are cryptocurrencies that, as far as I can tell, have either run their course or don't have a course in front of them to run.

When I have time, I investigate further and put as much information as I can gather into a summary next to one or more of the names.  

It is truly upsetting how many of these stories are the stories of obvious scams.

However, some patterns are emerging.  Here are some observations about the ones that DON'T appear to be obvious scams:  

• Alts have a plethora of different hashing algorithms, but there are really only three divisions that matter between their proof of work.  Either they are CPU dominated, GPU dominated, or they are mined with a particular kind of algorithm-specific ASIC.  ASICs exist for SHA256D coins like bitcoin and for Scrypt coins like Litecoin.  No other algorithm-specific hardware exists, so no other difference in hashing algorithm matters.
  
• Within each division, coins rapidly reach an equilibrium where whichever hardware generates their proof of work is allocated in direct proportion to the financial reward per minute of the block reward.   Usually this means that halving the block reward of an alt, other things being equal, halves the hashing power securing its block chain.
  
• Most alts become unstable when 3/4 or more of their coin supply has been mined (second reward halving), even if no other factors have made the cryptocurrency unstable prior to that time.  If the value being secured exceeds the block reward by too great a fraction, 51% attacks and forks are to be expected.  
  
• "Burst mining" or "automatically switching multipools" act like positive feedback amplifiers with a delay loop in mining - they make it VERY difficult for an alt to maintain a 'stable' block rate when its hash rate gets too small relative to the pool (GPU, CPU, or specific ASIC type) of hashing power it belongs to.  This is a heavy contributing factor in the 51% attacks and forks mentioned above.  
  
• Several alts switched to proof-of-stake after to this instability led to bad forks or "stuck" block chains where miners essentially had given up due to a burst miner leaving the chain at a ridiculously high difficulty level.
  
• A shift from proof-of-work to to proof-of-stake, whatever its effect on market value, has usually led to stagnation or decline in the community surrounding the alt.  In turn this usually leads to a collapse in value of the alt, unless heroic measures (such as direct giveaways by stakeholders to non-stakeholders) are used to bring people into the community.
  

Added.  Thanks for the report.

Ninety days, minimum.  :-)  It looks like it had a market cap below US$5K from May 16 to May 23.  If it stays above $5K until August 23, I'll decide it's probably not just a fluke recovery. 

Updates: 

Speedcoin, blitzcoin, coin2.0, emoticoin, and emucoin appear to have stopped trading, so I added them to the list or updated their existing entries.  Several new to the "dead" list had market cap higher than $5K at their last trade.

Ghostcoin, Highfivecoin, Parallaxcoin, and Suncoin all dropped below $5K market cap so I added them to the list as well.

It depends on the circumstances, of course... 

But exchanges and online wallets have a long history of occasionally goxxing their customers.

If you can secure your own machine, it's very much better to hold it yourself. 

If you can't .... well, if you can't you're better off trusting online wallets, but keep in mind that if you trust online wallets, then eventually you're going to get goxxed.  Manage your risk accordingly, and don't let any of them have so much of your savings that you'll be destroyed when it happens.

You could do that, but it would have to run a lot deeper than the QT client. 

You could hardfork Bitcoin with an additional transaction validity rule, that if an address has ever been previously used for a txout, then another transaction after block XXXX which also uses it for a txout is not valid.  It would be good for privacy, obviously. 

But it would increase the demands on computer resources required to validate the blockchain considerably, because they'd have to keep track of all txouts rather than just unspent txouts. 

I've considered this, mostly because it would shut down (existing) pools, and I think pools are bad because they can easily be used for attacks and the miners don't even necessarily know what they're hashing on.  But the reasons why people want to use pools would still be there, and they would just create a new pool protocol that conformed to the rule using BIP16 addresses (which they ought to do anyway). Ultimately, it wouldn't shut down pools, although it would make them more private.

The right way to get rid of pools is to do something that addresses the reasons (such as distributed pool software), rather than just firing the opening shot in something guaranteed to become an arms race.

Whenever you start the Bitcoin wallet it checks the Bitcoin blockchain.

There's a lot more of the bitcoin blockchain than there is of a typical altcoin blockchain.  It takes longer.

In principle, it could be optimized a lot.  In practice, it hasn't been.

Unreliably, if the history of other exchanges is any guide.

Seriously, don't get goxxed.  Keep your wallet yourself, and absolutely no more than you're comfortable with strangers losing anywhere else.

Exchanges eventually get hacked.  Or Mismanaged.  Or whatever.  Let them hold 0.01 BTC or whatever to keep your account open, and keep the rest where nobody else's mistake can put it at risk.

I'll reconsider when the Federal Deposit Insurance Co.  Insures BTC balances and the bitcoin exchanges meet its security and liability requirements.  And I'm not expecting that to happen during the current decade.

If your wallet is the old version, it will cheerfully go on downloading blocks created in the old-rules fork, even though there is a new-rules fork whose blocks it is refusing.  And the new-rules fork is the one that's actually going to continue.

So, yes, if there's a hard fork, be sure you have the latest wallet, REGARDLESS of whether you're still getting blocks.

Bitcoin blocks have rules.  If a block follows the rules your client knows, your client accepts it as valid.  If it doesn't, then your client will look for some block which does follow the rules it knows and accept that as valid. 

A hard fork happens when there are different clients out there on the network with different opinions as to what the rules are.  The blockchain reaches a point where there's a block that follows one version of the rules but not the other, and all the clients that follow that version of the rules will build on that block while all the clients that follow the other version of the rules won't. 

The usual reason why there is a hard fork is because of a software revision.  If that's the case, you want to get the new version immediately - even before the hard fork happens, the new version and the hard fork will be announced, so if you're staying up to date there is plenty of time to get it. 

Hard forks can also be caused by bugs, whenever those bugs cause the same code to have a different effect depending on compiler, hardware, operating system, or whatever.  If that's the case, it's an emergency.  In an emergency, if you don't know what's going on, you should shut down your client and wait for the emergency to pass.

I think there's some misunderstanding here.  

When I say that something was generated via coingen, I am NOT saying that was the end of its development.  Nor am I saying that it deserves to die for that reason.

When I say that something is dead, I'm not saying that that means it *ought* to be dead.  Bellacoin is a nice example of something that showed real innovation and worthwhile development, that really ought not have died. Although it might still pull through because its block chain is still running, it's close enough to death that I can't leave it off the list and have a list made according to a consistent, impartial rule.

Nor does it happen, in practice, that anything dies just because I say it is dead or dying.  I don't sentence things to death.  I just put up a monument so they won't be forgotten.  That's kind of like blaming the guy who carves the gravestones for the deaths.