Yeah, the problem with those ideas is that you want to try and keep all TX's on the mainchain as possible to pay miners fees, imo, so as to minimize cannibalizing or even killing off Bitcoin. Any of those offchain alternatives are  likely to create friction as well.

Thx for that.  It shows quite clearly that attempts to outgrow most of the scaling problems that vex Bitcoin by doing simplistic scaling are pretty futile which is a point of view that I held since before I bought my first BTC (on e-bay IIRC.)

I'm using the same computer now that I put together around the time Bitcoin was invented.  It's obsolete, but not horribly so.  i5 chipset (Nehalem), 4G, a few TB of mirrored encrypted storage, etc.  Sure, I could build a much better computer now (although not all that much better), but the ONLY reason I would have any need to do so would be to try to run a simple transfer node.  My network capacity has decreased by orders of magnitude since I moved out of the silicon valley so even at 7 TPS I probably would not try and if I did I would only activate it at hours when my data was not metered.

Upshot: I could still play a constructive support role in infrastructure support if I had good reason to.  One of the main reasons I do not is that if my contribution made much of a difference in a stressed situation where it would be of value is that my efforts could be nixed at a flip of the switch by simple injunctive measures (network censorship.)  Because Bitcoin dev has not focused on (or even acknowledged) this potential failure mode I feel little incentive to waste my time and money trying to support the robustness of the solution.

The chart shows that in roughly the short time I've been involved (mid 2011) we will be right back to where we are again with 20 MB (forgetting for a moment the little issue that is supposed to be forgotten that many people's 20MB has an exponential growth factor beyond that.)  There was a huge amount of low hanging fruit codebase-wise to harvest getting 1MB to work to the extent that it does.  That luxury will not be present moving into the 20 MB limit by the nature of how computer science is done.

I made several mis-calculations about Bitcoin at the time I put some actual fund into the blockchain:

1) That things would naturally centralize around such entities as blockchain.info, coinbase, etc, and thus alleviate the need to grow the transaction rate.  (A positive mis-calculation.)

2) That it would be so blatantly obvious that Bitcoin's only realistic trajectory would be as a backing store for similar solutions by the time we stressed the transaction rate limits that nobody could argue otherwise.  (A negative mis-calculation.)

edit: slight.  Also:

I would again note that the issue charted is UTXO which is not particularly related to transaction rate.  An attack I thought of years ago would be to formulate UTXO's systematically to chain blocks together in such a way that 1) their count would stress the working database (currently implemented in RAM most often) and 2) verifying them would touch as many blocks as possible making rendering of much of the actual blockchain itself require for many transactions.  I'm sure there is a name for such an attack.  If not, call it the 'tvbcof attack' I suppose.  I've not 'done the math', but it seems somewhat intuitive to me that such an 'attack' would happen organically upon reasonable use rates (which we have yet to even approach in the real-world to this point if Bitcoin remains a 'one-size-fits-all' exchange currency solution.)

but for every "bit of luck" the 49% attacker gets (by that i'm assuming you mean a "spurt" of luck with several blocks in a row) the 51% honest chain has the same chances of that "bit of luck" of a block spurt.  not only does the 51% honest chain have the advantage of slowly pulling further ahead via percentages alone while the 49% attacker is withholding blocks, he has the advantage of the same block spurt of luck.  both of these factors as the 51% chain pulls further and further ahead will eventually force the 49% attacker to abandon his attack, start over, while suffering losses from the blocks he could have claimed by publishing them instead of holding them back.  in effect, you can neutralize the spurt of blocks from the analysis and just say that the 51% chain will always outrun the 49% chain on average.

the only Sybil attack is the one going on in your head.

you got that right.

what's an OP to do?!

all i hear is a bunch of FUD.

so give me some evidence that the USG is performing a Sybil attack on all the pools.

also, explain to me how the USG controls Chinese mining pools in Mongolia.

huge inconsistency in logic for someone who claims to be logical.  or maybe it's just from someone who lacks comprehension of how Bitcoin incentives work in practice?

so if the pools didn't invest in their hardware, then logically you're referring to pools that aggregate individual mining power.  if that is the case, how can pool operators freely collude and sell out to banksters or any other attacker when those same individuals can just as freely yank their power out of the pool and point it elsewhere as we saw in ghash?

I understand the probability equations, but am trying to understand the logic in how they are being used and how an attacker with less than 50% could have an almost 100% chance of forcing a new longer chain. I would expect that no matter what the probability of being successful would be less than 50%.

I think there's two ways to look at it:

1.  Clearly, if an attacker has 50.0001%, then he has a 100% chance of eventually forging the longest chain.  If the attacker has 49.9999% instead, it makes sense that he'd have almost 100% chance, but not quite (why would it suddenly drop to less than 50%?).

2.  It's the attacker who gets to choose when to broadcast the attack chain.  Just by random luck, there's a good chance that at some point the attacker will hit a lucky streak and mine several blocks in quick succession.  When he hits this lucky streak and pulls ahead of the honest chain, he broadcasts his attack chain.

but assuming the attacker with 49% hashrate starts constructing his alternative secret chain at the same moment he pays for his toaster at the check out stand, there is absolutely no chance that he'll hit that lucky streak of block formation within the next hour or 6 blocks.