The company that runs BIT buys the bitcoins; investors do not.  Investors buy shares of BIT.  Originally there was a period of no redemptions until BIT was ready for that (April 2015?); there was some amount of time when redemptions were indeed available.  Since then that path for getting out is now closed.  Now there are no redemptions until the ETF is up.  Personally I bought into BIT with Roth IRA monies with no intention of ever selling; if it is goes to $0/btc then so be it; one less cruise during retirement?  Maybe.  If it goes to the moon then won't my kids be happy.

Ok, look.  Everyone stop mining except one guy (I'll volunteer) thereby minimizing/nearly eliminating the "waste"; well maybe we should have a few guys spread out for safety.  Those guys distribute the block reward and transaction fees gained in some, er, fashion to everyone that wants some.  Oh, the devil is in the details, isn't it?

If a thief is caught and still has the money then should they be forced to give it back?  If the thief gave it to their brother who still has it then should the brother be forced to give it back?  If the thief "bought" lunch from their brother-in-law who happens to own a restaurant then should the brother-in-law be forced to give it back?  When is the stolen money no longer rightfully the original owner's?

Even if money (BTC, etc.) is stolen at gunpoint?  Blacklisting stolen money is a marvelous idea.

To prepare for a potential life-threatening situation, one could have some money readily available but more not readily available.  The thief wants your fungible money; killing you is not their top priority.  Accessing your safe money should put your assailant at risk of capture.

My original stake was $10K non-retirement (average basis of right around $100/BTC) and then later $25K Roth IRA (basis around $700/BTC).  I did sell $5K worth of non-retirement BTCs (just to prove I could; and did claim the gain on my income taxes)) so my stake is down to $5K non-retirement.  Net:  $30K basis nominally worth $35K at the moment.  Since I'm strictly playing with my kid's money (so to speak), I might sell $30K more worth of non-retirement (reclaiming my original stake) at something <$340/BTC and just let the Roth IRA ride (house money so to speak) or wait until it's at the top of the next big bubble (although timing is so hard to do well).

One wonders if the block interval distribution pattern, although designed to target a 10 minute average, changes as the difficulty increases.  Where's the median?  What is the standard deviation?  Although it is mostly academic since the effective average suffices to analyze the backlog over long enough periods of time.  Then again a focus on the peaks to avoid breaking the memory pool is worth the effort.

The most provocative point is the one about miners constraining their block size; why do they do it?  What advantage do they gain?  Where can I learn more about header-first block transmission?

If the average transaction is 400 bytes then 20,000 transactions would only take up 8,000,000 bytes or about 8MB.  I just bet the memory pool is much larger than that.

The average transaction size is more like 400 bytes at best.

I've created a Google Sheet https://docs.google.com/spreadsheets/d/1lD50Q_NQOHAQk-q3X1hxh_Dlg-4SAujc1pa3UR4gVs0 to provide a tool for exploring backlogs.

Sweet.  So, since a single 1MB block can clear something like 2,400 transactions, it might take 5 or more blocks to clear a backlog of 12,000 transactions (if no more are flowing in (unlikely)).  Suppose we have a steady workload of 1,200 new transactions flowing in, in that situation it will take 10 blocks to clear the backlog;

average time	incoming	backlog
0	...	12,000
10m	1,200	10,800
20m	1,200	9,600
30m	1,200	8,400
40m	1,200	7,200
50m	1,200	6,000
60m	1,200	4,800
70m	1,200	3,600
80m	1,200	2,400
90m	1,200	1,200
100m	1,200	small

This is an unlikely scenario.  Clearly some burst of incoming transactions built up the backlog.  Every additional burst exceeding 2,400 per 10 minutes will grow the backlog more.

Ah.  So, the cost of computing the hash of a large block vs. a small one is negligible.  Once the hash of the proposed transaction set is calculated then it is included in the block header.  The block header does not vary in size.  Thank you.  I withdraw my proposal.

Guns and soup?  Too terrible to contemplate.  I will fallback on basic skills and hope cooperatives arise.

It seems to me, since the Roth IRA funds have already been taxed they are at less risk as compared to traditional IRAs which haven't been taxed yet.

I have both non-retirement and retirement investments.  If/when the rules for retirement investments are changed then we will have to evaluate the new rules and take action accordingly, e.g. withdraw despite penalties, etc.  As trouble rises then investment choices need to be adjusted.  Do you have specific investment advise based on your world view?

Ouch.  I thought I had at least the slightest clue, e.g. https://docs.google.com/spreadsheets/d/1mOTrqckdetCoRxY5QkVcyQ7Z0gcYIH-Dc0tu7t9f7tw, but please do help me understand.

Dec. 2012 -- my son gave me a Bitcoin as a Christmas present; best present ever.

Holding Bitcoin in a retirement account is not trivial; personally I am especially interested in Roth IRAs (I am predicting the future tax rate will be higher).  Holding an ETF in a retirement account is pretty straightforward although it does take a measure of trust (although not necessarily in a "central" authority).  What's needed is a viable ETF built on top of a block chain.

Naturally, as the block reward declines over time my proposal will mean less.  When the block reward is gone then my proposal will mean nothing.  My proposal does scale if/when we increase the maximum block size allowed.

It seems to me that miners could game the current system by deliberately mining minimal block sizes.  They would have a higher hash rate and win more often as compared to miners that try to mine larger blocks forcing them to do more iterations.

With my proposal above that would change, the miners would be motivated to mine the largest blocks possible helping to keep the queue of unconfirmed transactions low.

I had an idea; as I understand it the SHA-256 hash calculations dominate the compute time; essentially we are rewarding miners for their compute time.  In SHA-256, the payload of the first 512 bit iteration is 447 bits.  When more than 447 bits are being hashed additional iterations are required.  A payload of up to 959 bits is handled in two iterations.  1,471 bits are handled in 3 iterations.  In general, 512*N-65 bits are handled in N iterations.  Naturally more iterations take more compute power.  We could consider enhancing Bitcoin by awarding only a portion of the block reward based on the number of iterations needed.  A schedule like the following might make sense;

block size	block reward factor
minimal	0.1
small	0.2
medium	0.4
large	0.8
maximum	1.0