Possibly but this would just be another form of gross incompetence.  A cold wallet is only as secure as its txn data but in this case the cold wallet is only used to fill a hot wallet which makes hardening it against attacks very simple compared to other business models.

The cold wallet can contain the public key of the hot wallet.  The easiest way would be to use a single address for loading the hot wallet but HD wallets make it easier to preserve privacy without a loss of security.  If the hot wallet is using an HD wallet then the ExtendedPublicKey of the hot wallet is kept on the cold wallet machine and it only signs transactions sending an amount to the hot wallet and change back to itself.  This moves all the critical transaction information to the secure offline machine and makes a compromise of the online machine ineffective*.  This only applies in a situation where the cold wallet can be restricted to only send funds to a set of secure addresses.  A general use cold wallet may not have that luxury but an exchange does and everything should be done to harden the company wallet.

Example
For brevity the example uses a single key scenario but this can be done the same way using HD wallet extendedkeys and funds can be sent to ScriptHash (multisig address) instead of PubKeyHash (single key 'normal' address).

Cold Wallet Machine contains:
* Encrypted cold wallet private key
* Hot Wallet Public Key

Online Full node contains:
* Blockchain
* Bitcoind w/ connectivity to bitcoin network peers
* Cold wallet Public Key
* Hot wallet Public Key

STEP 1) Online Machine - use bitcoind and cold wallet public key to locate unspent outputs.  Create unsigned transaction sending funds from Cold Wallet to Hot Wallet with change back to cold wallet.
STEP 2) Online Machine -> Cold Wallet Machine - Transfer unsigned transaction* using offline method
STEP 3) Cold Wallet Machine - Independently verify the txn meets business rules (send acceptable value to hot wallet PubKeyHash and change back to Cold Wallet)
STEP 4) Cold Wallet Machine - Unlock private key and sign transaction.
STEP 5) Cold Wallet Machine -> Online Machine - Transfer signed transaction* using offline method
STEP 6) Online Machine - broadcast transaction to bitcoin network using bitcoind.

*There is another attack vector but it is difficult to exploit and complicates the explanation so it didn't cover it in the example but anyone designing a cold wallet should be aware of it.  A transaction input doesn't specify its value so an attacker could infect a user's online computer to provide false input information to the cold wallet.  The cold wallet may sign a txn thinking the inputs are worth 100 BTC when in reality they are worth 7,000 BTC.  Now if the cold wallet is only sending funds to known secure addresses this doesn't allow the attacker to send funds to any arbitrary address but they could cause the cold wallet to send the difference as a huge fee to miners.  If the attacker then prevented the broadcast of this transaction and mined it into a block he could steal funds this way.  To prevent this today requires giving the cold wallet not just the transaction but also the prior outputs it is spending so it can independently verify their value.   This is secure but greatly increases the complexity and the amount of data to be transferred.  If the txn format was updated so that the value of an input was specified this wouldn't be needed.  To change that however would require a soft fork or hard fork depending on how it was done.

That is correct.  There are no zero txn blocks because a block is invalid without a coinbase so people saying 'empty' blocks are referring to a block with just the coinbase txn.  This will occur periodically due to the way that blocks are constructed.  To understand why one needs to dig a little bit into what happens when a new block is found.  

A pool server may have thousands of workers working on the current block when a new block is found making that work stale. The server needs to quickly update all its workers to 'new work' and the longer that happens the more revenue that is lost.  If a new block is found on average in 600 seconds and it takes the pool just 6 seconds to update all its workers than its actual revenue will be 0.5% lower than its theoretical revenue.   So pools want to update all their workers as quickly as possible to be as efficient as possible.

To update workers to work on a new block the server must remove all the txn confirmed in the prior block from the memory pool, then organize them into a merkle tree and compute a new merkle root.  Part of that merkle tree is the coinbase txn which is unique for each worker (that is how your pool knows your shares are yours).  A different coinbase means a different merkle tree and root hash for each worker which can be time consuming to compute.  So to save time (and reduce stale losses) the pool server will compute the simplest possible merkle tree for each worker which is a single txn (the coinbase) push that out to all workers.  Compute the full txn set merkle tree and then provide that to workers once they request new work.  However if a worker solves a block with that first work assigned it will produce an 'empty' (technically one txn) block.

This is just one example of how a 1MB limit will never achieve 1MB throughput.  All the numbers in the OP assume an upper limit which is the theoretical situation of 100% of miners producing 1MB blocks with no orphans, inefficiencies, or stale work.  In reality miners targeting less than 1MB, orphans, and inefficiencies in the network will mean real throughput is going to be lower than the limit.  VISA only has an average txn capacity of 2,000 tps but their network can handle a peak traffic of 24,000 tps.  Nobody designs a system with a specific limit and then assumes throughput will be equal to that upper limit.

Target is not difficulty.

As gmaxwell said the network doesn't use difficulty at all.  It computes how small the next hash must be when the network adjusts.  That "how small" measure is expressed as a target.  You are right if hash <= target then it is a valid block but the question was about difficulty.

Now would be a good time for users of other services to question exactly that their exchange or wallet operate means when they say 'cold wallet'.  Cold wallet is just words.  Security is in the details.  I would not be surprised if there are other exchanges operating right now which believe bringing a wallet online for spending is still a 'cold' wallet.

No.  Bitcoin already has a very loose time synchronization.  Timestamps can be off as much as two hours and still be considered valid.  An extra second isn't even detectable.

An interesting concept. I need to spend some time digesting it but it is an interesting direction to take.   I think the biggest risk is the complexity factor.  Bitcoin is at a conceptual level very simple and yet the number of potential edge cases, attack vectors, and exploits is relatively large.  Take a more complex system and all the risks become harder to model.  Still that alone isn't a reason to discount it, just a risk factor.

Hacking a properly created cold wallet is impossible however it may not have been a properly created cold wallet
a) the wallet may have been created using compromised software (given how long the wallet has existed this is unlikely)
b) the randomly generated keys in the wallet may have had poor entropy (also unlikely)
c) the wallet was compromised due to poor signing with repeat k values (unlikely but can be verified from transaction history)
d) despite the company calling it a 'cold wallet' is wasn't a cold wallet* at all and was compromised just as any other hot wallet would be
e) someone (most likely an employee) with physical access to the cold wallet data file stole the coins

* A 'cold wallet' would be a private key or keys created by an offline machine and the private keys are never used on a machine that is or has been connected to the internet.  Signing of transactions should be done offline as well.  If you create a 'cold wallet' and then move it to a computer which is connected to the internet then it is no longer a cold wallet. 

No that is a purpose some people have invented after the fact.  The purpose of the 1MB temporary restriction was to limit the potential damage caused by bloating or spam attacks.   For essentially its entire history Bitcoin has effectively had an unlimited block size.  If the total txn volume is 100KB and the block size is 1MB then the block size has no effect on fees at all.  People paid fees to get timely inclusion in a block. We have never had a period of time where there were more txns than potential block space.

Some of the largest hacks in Bitcoin history have all involved services running on Linux.  Security is a mindset not an OS.  MtGox, BitStamp, Coinflor, MyBitcoin, Bitcoinica, Slush Pool, the Bitcoin faucet (the original), etc.  What did they all have in common?  They all ran on Linux and they were all robbed blind.

Maybe if the limit was higher.  Payment channels still require at least one transaction per payment channel set.  How often are you willing to reset payment channels?  Once per week, once per month, once per year? The longer the period the larger the initial escrowed amount.  How many payment channels if the average user going to have. Say the average user accepts escrowing 6 months worth of future payments and has 3 payment channels payees each.  BTW I consider this unrealistically low and of this was the upper limit most users would trade principles for convinience and user centralized services.  Still lets look at it as an upper bound. That still requires 6 on block transactions per user per year.  2 tps @ 6 txn per user =  10.5  million users.  

Do you really think Bitcoin will be a global revolution with an upper limit @ 10 million users?


Payment channels are a great concept but even they are hamstrung but a ridiculously low limit.  We wouldn't even be having this discussion if the limit was anywhere near realistic but it simply isn't. A 1MB cap is simply a joke.  It just guarantees that either Bitcoin dies on the vine or it is replaced by something superior. Payment channels, sidechains, and cross chain atomic transactions are transaction multipliers.  They move us from one economic transaction per block transaction to more than one economic transaction per block transaction and that is a great thing.  If natively a blockchain can support n users it can support xn users where x>1 using payment channels.  In essence they make the primary block space more efficient but efficiency only takes us so far.  You can't get any kind of scalability out of 1MB permanent limit.  It either remains perpetually a nerd toy or it is killed off by something which can scale.

This is the key point for US residents (not sure about how it is handled in other countries).  A loss doesn't occur until any chance of recovery is gone.  In this case it would be when you are either paid (some tiny %) or if you are not paid when MtGox completes bankruptcy and ceases to exist.

IIRC the trustee report indicated they had about 10% of the USD owed and about 20% of the BTC owed so in theory there is some funds remaining.  The bad news is the bankruptcy may stretch on for years and the court and trustee costs will be paid out of MtGox assets.  Until it is complete though under US tax code nobody has incurred a 'loss' yet.

They are. Personally I prefer to use a full node but that is just me.  Maybe someone who knows more about bc.i can chime in but I believe that you can pick the exact outputs you want to spend.  Just create a new transaction which only includes your confirmed outputs and it should confirm just fine.  If you the amount you need to send is more than the value of the output(s) which are already confirmed then you will need to wait.


In theory yes but I think that is unlikely.  The txn isn't that big and the fee isn't that low.  I believe eligus picks up low fee txns so it could be sent directly to them but I am not sure their requirements.  Honestly you probably just have to wait.

That is somewhat of a meta question.  There are actually no "bitcoins" just transactions.  So until this transaction confirms, the outputs the sender spent are still unspent so you could say the sender still has them.  It is important to realize that Bitcoins can't be "lost" in this manner, either the sender has them or the receiver has them.  There is never a period of time when neither party has 'them'.  The issue is that the network tries to make it difficult to double spend and thus while this txn is out there unconfirmed the network will actively try to prevent a double spend of it.  Even double spends with a corrected fee. Since you can't directly control any other node these type of problems are best avoided by paying the correct fee.

There is nothing you can do to make it confirm faster.  The sender sent 0.1 mBTC in fees but the minimum fee is 0.1mBTC per KB and the txn is 5KB.  To be compliant the txn should have paid 0.5mBTC not 0.1mBTC in fees.  Unless a miner is running custom software they treat a txn with a fee below the minimum as a txn with no fee.   You just need to wait.  It could be confirmed in an hour, or not confirmed in a day.  It all depends on if/when a miner will willing to pickup that big spammy transaction without a fee.  If the sender is using custom software that doesn't consider the transaction size this will continue to happen so if you expect payments from them in the future you may want to ask them to fix their code.

As far as spending most wallets will use confirmed txns over unconfirmed ones so if you spend an amount less than or equal to the value of the confirmed txn only (including the fee) then it should spend only that output.  If you need to spend an amount greater than that you will just need to wait.  If your wallet is picking unconfirmed outputs over confirmed ones that is also bad code.


D&T PSA:  Bitcoin fees are always expressed PER KILOBYTE.  If everyone writing code remembered that then there would be less unexpected results.  Paying a fee less than the minimum recommended amount is pointless either pay the full minimum or pay nothing. 

Cryddit's scenario also only considers a neutral scenario where the two networks go their separate ways.  Users who have coins prior to the fork have the same coins on both sides of the fork as well.  If one believes that the minority fork will die and thus the coins on that fork have no value they could be used to pay txn fees to buy up all the block space and help that inevitability occur much quicker.

Pre-fork coins however are valid on both networks which would mean making worthless transactions would result in losing coins on both forks due to fees.  One would obviously want to ensure these high fee transactions are valid only on the minority network.  The first thing would be to get a single output which is only valid on one chain.  Either the majority or the minority works so lets just look at the minority network.  The newly mined coins after the fork are only valid that chain.  For example at say block height 400,000 there will be two blocks 400,000a and 400,000b.  The coins from the coinbase reward in 400,000a can't be spent on the b network because they don't exist.  Even a single satoshi of post-fork coins can be used to turn pre-fork coins into post-fork coins.  A transaction which has as its inputs any number of pre-fork inputs plus at least one post fork input will create outputs which are spendable only on one of the forks.

100 BTC of prefork coins + 1 satoshi of post fork minority coinbase coins = 100.00000001 BTC worth of minority only coins.

Since this transaction can't exist on the majority network any txns which occur 'downstream' from it also can't exist on the majority network.  You could now spend this 100 BTC in fees on the minority network and still have the 100 BTC on the majority network.

Cryddit assumes after the fork occurs some miners will abandon it but lets be generous and assume that the full 5% continue to use the original network (if more than 5% do not support the fork it won't happen).  Lets also be generous and assume all build nothing but 1MB blocks (something miners today don't even do).  That would be only 7.2MB per day in block space.  To create paying txns which use up the entire block would only be 0.72 BTC per day in fees.  So just keep creating txns sending coins back to yourself paying a fee and use ensure all blocks are full.  Legitimate users however can pay higher than the minimum fee so it is just a question of how high you want to push the fees.   If you make txns with 10x the normal fee then everyone else will need to pay more than 10x the normal fee to get confirmations and that would only cost 7.2 BTC per day in fees.  

In the "1MB is a great idea" post I pointed out that if txn demand exceeds block capacity by some significant margin it will occur off-chain on centralized systems and those centralized systems will eventually consume all the block space for settlement transactions.  Since they can outpay direct users in txns fees they will squeeze out the direct users.  The high fee txns is a good way to illustrate that at no cost on the minority fork.  I think someone in this thread said Bitcoin would be great even if it cost $5 per transaction.  If the average txn is 500 bytes then $5 per txn would be $10,000 per MB or 288 BTC spent in fees per day.  That might be much for a single user to do but a group of users working together could do it.  No legitimate txn would ever be confirmed no matter how long they waited unless they paid more.

DISCLAIMER: This is more an academic exercise than a practical suggestion.  Despite all the FUD I think when the fork happens the other chain will simply die off.  I would strongly discourage performing this unless you completely understand the concept of transaction validity across parallel forks.  If you think Bitcoin works on addresses and balances you will probably lose your Bitcoins on both forks by creating txns which are valid on both forks.

I don't recall that being the case but I could be wrong (on other issues my opinion has changed over time ).  I do recall around that time (I assume you mean v0.9.0 not v0.0.9) the backlog of unconfirmed transactions was growing.  The reason is that while the soft limit had been raised the default value hard coded in the bitcoind was 250KB and most miners never changed that.  The only miners which were targeting a different size were targeting smaller not larger blocks.  Even as the backlog grew they felt no urgency in changing it.  Some uninformed people advocated raising the 1MB cap as a way to "fix" the problem.  I tried (and mostly) failed explaining that miners could already make blocks at least 4x larger and were opting not to.  Changing the max only allows larger blocks if miners decide to make them.  The developers ended up forcing the issue by first raising the default block size so that it didn't remain fixed at 250KB and them removing the default size all together.  Today bitcoind require you to set an explicit block size.  If you don't set one you can't mine.


I have to disagree.  Bitcoin is a protocol and protocols change overtime.  Constantly reinventing the wheel means a lot of wasted effort.  You end up with dozens of half used systems instead of one powerful one.  Look at TCP/IP or even HTML.  Yeah they have a lot of flaws, they also have a lot of early assumptions backed in which produce inefficiency.  Evolution is also hard. Look at the mess of browser standards or how long the migration to IPv6 has taken.  Despite the problems the world is better for having widely deployed protocols in favor on constantly starting over.  

In the crypto space however 'starting over' means a chance at catching lightning in a bottle and becoming insanely rich.  That has lead to a lot of attempts but not much has come from it so far.  Alternates are an option but they shouldn't be the first option.  The first option should be evolution but if a proposal fails and a developer strongly believes that in the long run the network can't be successful without it then it should be explored in an alternate system.  There are some things about Bitcoin which may be impossible to change and for those an alternate might be the only choice.  The block size isn't one of them.

Jumping specifically to the block size.  The original client had no* block size limit. The fork occurred when it was capped down to 1MB.  The 1MB has in some circles become a holy text but there isn't anything which indicates it had any significance at that time.  It was a crude way to limit the damage caused by spam or a malicious attacker.  It is important to understand that the cap doesn't even stop spam (either malicious or just wasteful).  The cost of mining, the dust limit and the min fee to relay low priority txns are what reduced spam by making it less economical.

The cap still allowed the potential for abuse but the scope of that abuse is limited.  If 10% of the early blocks were maxed out it would still have added 5GB per year to the blockchain size.  That would have been bad but it would have been survivable and would have required the consent of 10% of the hashrate.  Without the cap a single malicious entity could have increased the cost of joining the network by a lot more.  Imagine if before you even knew about Bitcoin and the only client was the full node that to join the network would have required downloading 100GB or 500GB.  Would Bitcoin even be here today if that had happened?  

Satoshi stated in the white paper that consensus rules can be changed if needed.  He also directly stated that the block limit was temporary and could be increased in the future and phased in at a higher block.  Now I am not saying everything Satoshi said is right but I have to disagree that the 'original principles of decentralization and fairness' preclude changes to the protocol.  Some people may today believe that any change invalidations the original principles but that was never stated as an original principle. The protocol has always been changeable by an 'economic majority' and the likewise that majority can't prevent the minority from continuing to operate the unmodified protocol.  It is impossible to design an open protocol which can't be changed however as a practical matter a fork (any fork) will only be successful if a supermajority of users, miners, developers, companies, service providers, etc support the change.

There are four universal truths about open source peer to peer networks:
a) It is not possible to prevent a change to the protocol.
b) A change in the protocol will lead to two mutually incompatible networks.
c) These parallel networks will continue to exist until one network is abandoned completely.
d) There is no mechanism to force users to switch networks so integration is only possible through voluntary action.

There is a concept called the tyranny of the minority.  It isn't possible for a protocol to prevent changes without explicit approval of every single user but even if it was that would not be an anti-fragile system.  A bank could purchase a single satoshi, hang on to it, and use that as a way to prevent any improvements to the protocol ensuring it will eventually fail.  The earliest fork fixed a bug which allowed to the creation of billions of coins.  There is no evidence it has universal support.  The person who used it to create additional coins saw the new version erased coins that the prior network declared valid.  Still a fork is best if either a negligible number of people support it or a negligible number of people oppose it.  The worst case scenario would be a roughly 50-50 split and both forks continuing to co-exist.  

The original client did have a 33.5MB constraint on a message length.   It could be viewed as an implicit limit on block sizes as the current protocol transmits complete blocks as a single message.  There is nothing to indicate that Satoshi either intended this to be permanent or that it was a foundational part of the protocol.  It is a simplistic constraint that prevents an attack were a malicious or bugged client sends nodes an incredibly long message which needs to be received before it can be processed and invalidated.  Imagine your client having to download an 80TB message before it could determine that the message was invalid and then doing that a dozen times before banning that node.  Sanity checks are always a good idea to remove edge cases.

Indeed and this fits with expectation for a couple of reasons.  The first is that P2PkH ("normal") transactions are the most compact.  For a given number of inputs and outputs any other script is going to be larger.  Even a relatively simple 2-of-3 multisig script is about 50% larger than a Pay2PubKeyHash script and there is a lot more potential than just straight multikey transactions.  The good news is that the complex scripts is where all the interesting innovation is going to come from.  Without the scripting Bitcoin wouldn't be programmable money it would just be digital cash.  Now a digital cash system is interesting but scripting is what allows doing interesting things in a trustless manner.  

Adding to that the average number of inputs and outputs per transaction has risen over time.  As the number of users increases the total number of outputs will also increase.  While individual transactions will vary for the overall blockchain the number of inputs and outputs will be roughly the same.  We can think of inputs and outputs as a single roundtrip script.  The other elements of the transaction are relatively small and fixed in size so:

Average txn size = (Script Complexity) * (Number of IO)

The bottom line is both elements of transaction size are increasing slowly over time.  Unless adoption dies off (in which case all this is academic) there is no reason to believe that trend will change anytime soon.  The good news is that average transaction size will probably not go above 800 or so bytes so I think a very conservative estimate of throughput is at least 2.0 tps per MB.

Nice to see other data points which line up with the OP.  500 bytes per txn would equate to 3.3 tps max per MB and 600 bytes would be 2.7 tps per MB.  In the OP I expanded that to cover the likely transaction size growth and to all provide a lower bound for an unrealistic but at least possible txn size.  Rounding it all out that is why most of the arguments revolved around a sustainable 2 to 4 tps (per MB).  If you read anything on the topic about scalability which uses values outside that range I would question the knowledge of the author.  I see lots of good intended articles which cling to the gospel of 7tps.

* As a side note in an optimal world there would have been no scripts in the output portion of the txn.  Output would just contain a 20 byte field to contain the ScriptHash.  All transactions would involve paying to a scriptHash and all addresses would be encoded ScriptHashes.  Even today the most common script would probably be P2PkH but it would "work" the same way as any other arbitrary script.  We probably are never going to change this but it could be done as a hardfork.  In addition to simplicity and consistency it would make the UTXO smaller with compact fixed length records  without any loss of functionality.  Related to that store outputs as a merkle tree and you could have intra-transaction pruning as well.

In the stock trading world, fill or kill is trade type which indicates the order should either execute immediately or be deleted.   Could something like this be used in a blockchain based system to prevent "stuck" transactions?

The problem:
Due to outdated priority rules, user misunderstanding, or wallet bugs users can create transactions which are very unlikely to confirm or even be relayed through most nodes.  However most wallets have no good method to cancel.  Cancelling txns is complex.  A simple cancel button would creating confusion and unexpected results.  The wallet software could remove the txn locally but it can't force other nodes to remove their copies.  This means the txn could be 'confirmed' long after it is 'canceled'.  Waiting is also not a good solution and can be confusing to users.  The time before a txn is removed from a node's memory pool is not static and the txn may be removed from some but not all nodes.  Many clients will continue to rebroadcast unconfirmed txns which 'reset' the clock.  Users also have no way of knowing if copies of the txn remain.  This means the network appears to have 'inconsistent' behavior.   Something more robust is needed to provide deterministic behavior.

The solution:
What about including a max block height flag?  This could be setup very similar to nlocktime except that it would designate the last block the txn can be confirmed in, instead of the first one.  Once the kof height has been created the txn would no longer be valid for inclusion in a block.  To simplify dealing with reorgs it would be a good idea for nodes to keep the txn in the memory pool but not considered for inclusion in a block until the current block height is a small number of blocks ahead of the kof height and then delete the txn.  The user would have a high level of confidence that after the kof height the txn could be resubmitted to the network with a more appropriate fee.  The user's client would change the status of the txn to canceled once the kof height has been passed and increase the 'available balance' which would be consistent with user expectations and help to hide the network behavior in a deterministic manner.

Any potential attack vectors or complications?

Yeah they imagine some kind of romantic war but there are only two scenarios
a) the fork doesn't get support and thus never happens (or is postponed)
b) the fork occurs only after a super majority of miners, full nodes, merchants, and users are already supporting it.

I guess nobody remembers the P2SH rollout.

Corrected it for you.

Bitcoin relies on the second preimage resistance of the hashing function.  If you can find a second input that produces the same output of a single hashing function [ SHA256(x) == SHA256(y) ] then the output of the second round of hashing will also be identical [ If SHA256(x) == SHA256(y) then SHA256(SHA256(x) == SHA256(SHA256(y)) ].

Satoshi seemed overly fond of double hashing algorithms SHA-256(SHA-256(x)) and RIPEMD-160(SHA-256()).  To my knowledge he never provided an explanation.  A common usage of double hashing is to prevent length extension attacks but this is a very specific kind of attack which is applicable to Bitcoin.  Honestly it really serves no purpose, a simple RIPEMD-160 of the PubKey (or Script) would have worked equally well.  We probably will never know for sure.

There are a few other design choices which are best chalked up to "they are that way because Satoshi made it that way".