Some technical and economic concerns

[luxgladius]

Greetings all,

A buddy posted a link to a story about Bitcoin the other day, and I've spent some time since trying to parse out the system. I downloaded the source code and read through some of the interesting parts, and I now feel I have a pretty good handle on how it "works." That said, I do have a few questions, and I hope that some veterans around here might help to enlighten me.

Let me start by killing a sacred cow. Satoshi clearly had a great idea when it came to the structure of Bitcoin, but some of his coding seems ad hoc and arbitrary to me. It's understandable really, at some point you just have to make a choice between spending days of theoretical analysis or actually getting down to writing code. Consequently, the following will address some of the limits that are programmed into the software, so prepare yourself if you are a hardcore "Satoshi-ist".

1. The ten-minute limit: The Bitcoin system is designed so that a block is produced, on average, every ten minutes. The reasoning is clear, he wanted to find a value that's long enough that block traffic doesn't swamp the network and transactions have time to reach every miner, but not so long that it takes forever for transactions to get traction with a number of confirmed blocks. However, I'm wondering if the ten minute time is really the best. For one thing, I think it stands in the way of Bitcoin ever being used as an "everyday" currency system. Most restaurants aren't going to want to wait 30 minutes to make sure your money's good before giving you your cup of coffee.

I'm curious if transitioning to a more rapid scheme is being considered as the network grows. Perhaps a move to a block per minute or two, with a corresponding drop in the subsidy value from 50 to 5 or 10. Would this increase the incidence of orphaned block chains too much? I know it's difficult to study how quickly a block propagates across the network, but it seems that if we waited 2 or 3 times the average time (when in theory 95-99.7% of the network has received the block), it would probably be safe and more responsive. This would also have the benefit of increasing the granularity of how the money is distributed, in that instead of having 50 Bitcoins distributed to one miner, you will have 5-10 miners with 5-10 Bitcoins each. It seems like a good direction to go if the system can support it.

2. The 4 year drop: Almost everybody knows that the ultimate number of Bitcoins will be somewhat under 21 million. However, in the code, this is implemented by a 50% drop in subsidy value every 210,000 blocks (approximately 4 years, less now that the network is growing so quickly though). It seems like having a drastic drop like that could lead to some nasty effects. All of a sudden, every mining rig in the world will be producing half as many Bitcoins. (Ok, more than half, but the fees are a pretty nominal percentage of a miner's income.) My admittedly basic understanding of economics tells me that up to that point, if the market has reached equilibrium, there will be just as many miners producing Bitcoins as is profitable. With that drop, it's hard to imagine a substantial fraction not taking their machines offline and scaling down. This will have the effect of significantly dropping the network power, which will make blocks occur less often. The difficulty only resets every approximately two weeks, and with the power reduced, it will make blocks take longer to mine. Not only does this mean transaction confirmations will be even slower, but also the system will take longer to adjust, which means that even more miners may be forced out, which means the adjustment period will be longer, and you see where I'm going with this. Certainly a new equilibrium will be found eventually, but a step response to a system is usually a bad idea from a controls perspective.

I don't see why rather than having the sudden drop, we couldn't have a gradual phase out if economic reasons really dictate that the subsidy must be reduced. I suppose it depends on how quickly people lose their wallet files, if the goal is to keep the money supply in circulation relatively constant. I'm an engineer, not an economist, I know next to nothing aside from what I learned in Microecon 101. But if the community started reducing the subsidy by .5 mBTC/block after block height 160,000 or 1 mBTC/block after 185,000, it would give the same 25 BTC reduction in subsidy with what seems a much less abrupt hit to the miners.

As a follow-up, I'm aware that these limits and algorithms are hardcoded into the system now, and would require a change to every client in existence. However, that's not a sufficient reason to not have them implemented as long as sufficient time is given for the community to accept them. The Bitcoin is a currency of consensus, and those who run counter to the consensus would simply find their blocks rejected by the network. I just say this to hopefully shut down some of the "it's part of the algorithm, it can't be changed" responses I might otherwise get. Also, I'm not as much actively arguing for these changes as I am looking to see if these issues have been/are being considered, and if so, what the community thought upon them is. It's the kind of stuff you really don't find in the FAQs.

Thanks for taking the time to read. I look forward to an interesting discussion.

[1714158230]

1714158230

[1714158230]

1714158230

[1714158230]

1714158230

[1714158230]

1714158230

[BeeCee1]

3.  the two week difficulty reset.

[luxgladius]

3.  the two week difficulty reset.

Well, it's clear that the difficulty has to be adjusted in some way with some statistical significance, so I don't see the 2016 block reset as a major concern. What are your issues with it? Too long and jumpy? I guess a 1008 block size would still be fine, and if the blocks were reduced in difficulty, as above,  they could still be calculated with the same statistical significance in much lower time so that would be another advantage. Of course, the optimum would probably be some kind of Kalman filter where the difficulty is updated with every block, but I think it's actually a good idea to keep the implementation simple so less is likely to go wrong.

[Stephen Gornick]

1. The ten-minute limit: The Bitcoin system is designed so that a block is produced, on average, every ten Most restaurants aren't going to want to wait 30 minutes to make sure your money's good before giving you your cup of coffee.

Perhaps a move to a block per minute or two,

Bitcoin wasn't meant to allow instant confirmation.  That 10 minute wait was determined as the length necessary due to latency on a global network.  

Obviously, that type of payment represents a lot of payment volume that bitcoin is leaving on the table.  There have been multiple ideas on how to allow bitcoin to serve this function.   None of the ideas address reducing the length of time to confirm blocks as there's no lower value that would solve the "point of sale" problem yet would still allow Bitcoin to work.  As [Mike] from the forum put it, you either are "< 5 seconds or > 5 seconds".  So neither 1 minute nor 10 minutes to confirm makes a difference for making point of sale more possible.

Right now, there is a solution.  As long as both the merchant and customer use the same ewallet provider, transactions can be instantaneous.  MyBitcoin works this way already today.    Similarly, another solution might be simply to advance some amount to an account with the merchant or with some other intermediary.  Consider if the mobile point of sale vendor Tabbed Out were to add bitcoins as a payment method, for example.  They would hold your coins in their wallet so those coins would be spendable instantly regardless of which restaurant you dined at.  With those solutions, however, you have the drawbacks where you must extend trust to an intermediary and also will lose some privacy.

One other idea includes a pure bitcoin method where low value transactions might be accepted as payment on receipt by the merchant with no confirmations.  This method assumes however that there are listening posts on the network that would monitor for double spends and alert the merchants after any double spend attempts were discovered.

Additionally, there have been reports that work is underway to integrate bitcoin with the Open Transactions platform to allow transactions that are both anonymous (as far as the merchant knowing the buyer) and also are instant, requiring no confirmations. This too requires pre-paying bitcoins to the OT account that will be used for spending.

2. It seems like having a drastic drop like that could lead to some nasty effects.

With that drop, it's hard to imagine a substantial fraction not taking their machines offline and scaling down.

When it happens the drop from 50 to 25 will not come as a surprise.  

Considering the worst case you describe (50% of mining capacity drops in response), instead of 14 days of 10 minute block confirmations it is 28 days of 20 minute block confirmations.  Since transaction fees reflect a growing part of the block bounty, a 50% reduction in currency issued will not have a 50% reduction of income to the miners.  Even so, is this big drop to the miners going to be felt? Yes.  Is it a serious enough problem to force a change to the protocol? I wouldn't think so.

The fact that miners "get hit" is really not a concern.  Bitcoin is likely already well beyond the amount of mining necessary to be protected from an attacker with lots of hashing power.  It likely could survive just fine if half the the miners it currently has were to disappear at any point in time.

I'm aware that these limits and algorithms are hardcoded into the system now, and would require a change to every client in existence. However, that's not a sufficient reason to not have them implemented.

it's part of the algorithm, it can't be changed.  :-)

[luxgladius]

1. The ten-minute limit: The Bitcoin system is designed so that a block is produced, on average, every ten Most restaurants aren't going to want to wait 30 minutes to make sure your money's good before giving you your cup of coffee.

Perhaps a move to a block per minute or two,

Bitcoin wasn't meant to allow instant confirmation.  That 10 minute wait was determined as the length necessary due to latency on a global network.

I guess that's my question. How was this 10 minute wait chosen? It has the feel of a number that was just picked out of the air, and obviously it couldn't be tested as the network exists today, because the network didn't exist. Is it agreed that higher block volume would be more advantageous in the long run? Aside from the headers, I don' think it would increase the bandwidth requirement of the network. There would be more blocks, but they would contain fewer transactions. If the study hasn't been done yet, maybe I can do some parsing magic and see how long on average a block takes to get to me from the time it claims it was originated. Not perfect since the clients aren't guaranteed to have synchronized clocks, but better than nothing.

Obviously, that type of payment represents a lot of payment volume that bitcoin is leaving on the table.  There have been multiple ideas on how to allow bitcoin to serve this function.   None of the ideas address reducing the length of time to confirm blocks as there's no lower value that would solve the "point of sale" problem yet would still allow Bitcoin to work.  As [Mike] from the forum put it, you either are "< 5 seconds or > 5 seconds".  So neither 1 minute nor 10 minutes to confirm makes a difference for making point of sale more possible.

Fair enough. Though it seems like an escrow system could work in this case with a 2-3 minute wait being acceptable.

Scenario: Alf walks into Bernie's restaurant. Bernie seats him and asks for a proof of credit. Alf authorizes a transaction on his NiftyBitcoin(TM) device for some amount that's sure to be enough to cover his meal, keyed to require both his and Bernie's signature to unlock. (This kind of transaction is actually possible with the existing system, which is a credit to Satoshi for having foresight. Of course, the official client doesn't support it yet, but the protocol does.) He then proceeds to place his drink order. Bernie brings by his drink, and while he does so, he receives confirmation that the transaction is now three blocks into the network, which is possible because of the average 1 minute block time. Bernie then takes his meal order, Alf eats his food, and at the end, they both authorize a transaction from the escrow account into their own respective accounts. (The bill amount and the "change", respectively.) If anything goes wrong and Bernie proves untrustworthy, then Alf is only out the cost of an expensive meal and Bernie gets nothing. Likewise if Alf refuses to pay, Bernie is out only the cost of the food and Alf has at least lost his money. (And he'll be subject to standard dine-and-ditch laws.)

Right now, there is a solution.  As long as both the merchant and customer use the same ewallet provider, transactions can be instantaneous.  MyBitcoin works this way already today.    Similarly, another solution might be simply to advance some amount to an account with the merchant or with some other intermediary.  Consider if the mobile point of sale vendor Tabbed Out were to add bitcoins as a payment method, for example.  They would hold your coins in their wallet so those coins would be spendable instantly regardless of which restaurant you dined at.  With those solutions, however, you have the drawbacks where you must extend trust to an intermediary and lose some privacy.

One other idea includes a pure bitcoin method where low value transactions might be allowed on receipt by the merchant with no confirmations.  This method assumes however that there are listening posts on the network that would monitor for double spends and alert the merchants after any double spend attempts were discovered.

Additionally, there have been reports that work is underway to integrate bitcoin with the Open Transactions platform to allow transactions that are both anonymous (as far as the merchant knowing the buyer) and also are instant, requiring no confirmations. This too requires pre-paying bitcoins to the OT account that will be used for spending.

It seems like all of these scenarios require a trusted third party, which seems somewhat counter to what Bitcoin's vision is. With a central point of confirmation, you're still having a central point at which skullduggery can take place, funds can be seized, accounts can be frozen, etc. The requirement that both have the same merchant just exacerbates this problem, as this means that the system will gravitate towards centralization with powerful merchants (VISA, AMEX, etc.) having de facto control of your Bitcoins.

2. It seems like having a drastic drop like that could lead to some nasty effects.

With that drop, it's hard to imagine a substantial fraction not taking their machines offline and scaling down.

When it happens the drop from 50 to 25 will not come as a surprise.  

Considering the worst case you describe (50% of mining capacity drops in response), instead of 14 days of 10 minute block confirmations it is 28 days of 20 minute block confirmations.  Since transaction fees reflect a growing part of the block bounty, a 50% reduction in currency issued will not have a 50% reduction of income to the miners.  Eve so, is this big drop to the miners going to be felt? Yes.  Is it a serious enough problem to force a change to the protocol? I wouldn't think so.

The fact that miners "get hit" is really not a concern.  Bitcoin is likely already well beyond the amount of mining necessary to be protected from an attacker with lots of hashing power.  It likely could survive just fine if half the the miners it currently has were to disappear at any point in time.

I'm less concerned about the miners "getting hit" rather than the effect that will have on the system in terms of a dynamic response. As I said, yes, the market will find a new equilibrium eventually, but in the meantime, the rate of incoming blocks will be reduced and each block will produce less, so the system will become clunky. Miners may panic and pull out. The network rate drops more. However, this causes the cost of Bitcoins to rise, so after the next difficulty correction, miners get back into it at some level. The increased power requires another drastic correction to difficulty, and the network gets clunky again. Repeat ad (market) nauseam.

My point is, if we can avoid this underdamped response to the change by making it gradual rather than abrupt, I would think it would be better for the system as a whole.

I'm aware that these limits and algorithms are hardcoded into the system now, and would require a change to every client in existence. However, that's not a sufficient reason to not have them implemented.

it's part of the algorithm, it can't be changed.  :-)

Stand back, I'm about to do the impossible!

Old code:

Code:

int64 GetBlockValue(int nHeight, int64 nFees)
{
    int64 nSubsidy = 50 * COIN;

    // Subsidy is cut in half every 4 years
    nSubsidy >>= (nHeight / 210000);

    return nSubsidy + nFees;
}

New code:

Code:

#define RAMPTHRESHOLD 185000
// Make sure RAMPTHRESHOLD divides evenly, or something bad might happen
#define RAMPINCREMENT (25*COIN/(210000-RAMPTHRESHOLD))
int64 GetBlockValue(int nHeight, int64 nFees)
{
    assert(nHeight >= 0);
    int64 nSubsidy = 50 * COIN;
    // Subsidy is cut in half every 4 years (but with a gradual rampdown)
    nSubsidy >>= (nHeight / 210000);
    int nHeightInInterval = nHeight % 210000;
    if(nHeightInInterval >= RAMPTHRESHOLD)
    {
        nSubsidy -= (RAMPINCREMENT*(nHeightInInterval-RAMPTHRESHOLD)) >> (nHeight/210000);
    }

    return nSubsidy + nFees;
}

MtGox and other assorted major exchanges/vendors with foresight: We will only honor Bitcoins generated with the new code after block 185000.
Community: Does it affect anything we're doing in our money-crazed ways right now? No? Then ok.

[Stephen Gornick]

Stand back, I'm about to do the impossible!

Creating a fork is not impossible.  What is likely impossible will be convincing the bitcoin community to incorporate your fork which, to me, addresses only a temporary and minor adjustment occurring at known points of time in the future.

More importantly, I think you significantly overlook a little detail.

Bitcoin absolutely relies on trust.  Trust that the rules (the protocol) will not be mucked with.   That the protocol can survive as-is, and not require a change whenever someone comes up with suggestions for improvements or perceives it to somehow be flawed.

Fortunately, if a serious issue does appear, it is technically possible for the protocol to be added to or modified.  For something like this though, that probably won't be happening.

[edited, removed strikeout from words]

[citryphus]

I think that when payouts are cut and mining power decreases, the difficulty will reset to preserve the 6 blocks an hour. Also, transaction fees will be an incentive to keep mining as payouts decrease.

[k]

Right now, there is a solution.  As long as both the merchant and customer use the same ewallet provider, transactions can be instantaneous.  MyBitcoin works this way already today.    Similarly, another solution might be simply to advance some amount to an account with the merchant or with some other intermediary.  Consider if the mobile point of sale vendor Tabbed Out were to add bitcoins as a payment method, for example.  They would hold your coins in their wallet so those coins would be spendable instantly regardless of which restaurant you dined at.  With those solutions, however, you have the drawbacks where you must extend trust to an intermediary and lose some privacy.

One other idea includes a pure bitcoin method where low value transactions might be allowed on receipt by the merchant with no confirmations.  This method assumes however that there are listening posts on the network that would monitor for double spends and alert the merchants after any double spend attempts were discovered.

Additionally, there have been reports that work is underway to integrate bitcoin with the Open Transactions platform to allow transactions that are both anonymous (as far as the merchant knowing the buyer) and also are instant, requiring no confirmations. This too requires pre-paying bitcoins to the OT account that will be used for spending.

It seems like all of these scenarios require a trusted third party, which seems somewhat counter to what Bitcoin's vision is. With a central point of confirmation, you're still having a central point at which skullduggery can take place, funds can be seized, accounts can be frozen, etc. The requirement that both have the same merchant just exacerbates this problem, as this means that the system will gravitate towards centralization with powerful merchants (VISA, AMEX, etc.) having de facto control of your Bitcoins.

I'm not an expert on the Open Transactions platform mentioned by Stephen above, but I believe that it doesn't require a trusted third party (e.g. VISA, AMEX etc.).  It seems it could allow instant payments so would be complementary to bitcoin.
I think it was developed by someone known as Fellow Traveler. I just listened to this Cypherpunkd episode today http://agoristradio.com/?p=234 about it. I'm interested in learning more about it.

[luxgladius]

Creating a fork is not impossible.  What is likely impossible will be convincing the bitcoin community to incorporate your fork which, to me, addresses only a temporary and minor adjustment occurring at known points of time in the future.

My apologies if I was overly flip in response to your own sally. My point was just that the difficulty is not in changing the code, but just in getting adoption by the consensus of the community. I said as much in my first post, so I don't disagree. I just don't see a reason that a consensus can't be formed if the community is at all reasonable. You haven't really argued with my reasoning, you've just said that a) it may not be bad enough to merit a change, and b) it only happens once every four years. Both true, but personally, if a protocol has a systematic flaw, even if the flaw is infrequent, I'd like to correct it rather than just let it be. And I still think that it will be a really bad time for the performance of the network, if the miner supply economy is at all matured at that point. The forewarning might mean that some get out ahead of time, though I think they'll all keep mining as long as they can make the most profit, and when it becomes unprofitable, get out or scale back to the point where it does. I don't think 50% would quit, as you posited above, but I wouldn't rule out a third.

As to the fees, I'm going to pick the latest ten fees as I write this post: 0, 0.0805, 0.13455706, 0.0905, 0.1535, 0.1365, 0.05, 0.26886086, 0.0305, 0. So, the total BTC mined by these transactions is 500.944, of which 500 are subsidized Bitcoins and 0.944 (about 0.19%) is fees. So really, I think we can neglect fees at least for the near future as a factor in miner income, unless there's a reason to expect they're going to grow dramatically over the next year.

More importantly, I think you significantly overlook a little detail.

Bitcoin absolutely relies on trust.  Trust that the rules (the protocol) will not be mucked with.   That the protocol can survive as-is, and not require a change whenever someone comes up with suggestions for improvements or perceives it to somehow be flawed.

You seem to have an almost religious faith and conviction about the fitness of the Bitcoin protocol. Do you believe that the algorithm as it exists is really the best that could be done and is not at all in need of any improvement? It's an impressive protocol, but I doubt even the original author would make that assertion. He's not a prophet, and the code isn't written with the finger of God. There have already been technical errors found and corrected, and algorithmic flaws like this are, in my opinion, of just as high an importance.

I prefer to say Bitcoin relies on consensus. Trust implies that you believe that your own judgment is inadequate and you have to substitute that of others. Consensus means that many informed people have made their own judgments and come to an agreement. That said, there is a certain plan and expectation laid out that can be considered a form of contract with the community, but I don't think tweaks that only apply to far future operation and only aim to fix flaws coming from the ad hoc initial implementation of the protocol are terrible. At the most you could claim that reducing the subsidy incrementally as described above would decrease the terminal number of bitcoins. Personally, I don't think that's a big deal, but if so, you could implement the ramp balanced around the transition point, and that would net to exactly zero change in the total number. Likewise changes like the rebalancing to 1 or 2 minutes per block that only improve the function of the network and don't degrade it are probably acceptable, as long as nobody's making money that they wouldn't be making anyway. The only reason to reject changes that have only upside and no downside would be hidebound stubbornness as far as I can see, the same kind of dogmatic inertia that plagues the worst types of conservatives. (And I'm fairly conservative myself, for what it's worth.)

That's not to say the changes I discuss above have only upside. Part of my hope in this initial post was to gather information to try to determine whether there was a downside, and I still hope to learn more.

However, at this stage in the project, I think there is enough centralization that these minor changes, which change the "letter" of the protocol while keeping intact the spirit, could reasonably be addressed. If the main development group announced support of the changes, incorporated them into the client, and got the major exchanges and vendors on board, the community would follow. Why wouldn't they? If the changes were made around block 185000, that would be a year for the changes to propagate around the net. If it were 197500 for the balanced ramp, that would be even longer. I'd be surprised if anybody went that long without adopting new software versions. Of course, the closer in time we get, the harder it would be to push through adoption, so that's why it's a question for now and not later. Are these, or any other changes, worth fighting for? And that is the reason for this discussion.

[luxgladius]

I think that when payouts are cut and mining power decreases, the difficulty will reset to preserve the 6 blocks an hour. Also, transaction fees will be an incentive to keep mining as payouts decrease.

It will, but at the least it will be a rough 3-4 weeks until it does, and the question is why do we want that?

I'm not an expert on the Open Transactions platform mentioned by Stephen above, but I believe that it doesn't require a trusted third party (e.g. VISA, AMEX etc.).  It seems it could allow instant payments so would be complementary to bitcoin.
I think it was developed by someone known as Fellow Traveler. I just listened to this Cypherpunkd episode today http://agoristradio.com/?p=234 about it. I'm interested in learning more about it.

My understanding is that Open Transactions rely on an external server for verification, so in that sense they are dependent on a third party. If the server's down, the transaction can't be marked spent. The "Open" part about them is that anybody can set up a server and issue currency.

[Stephen Gornick]

I still think that it will be a really bad time for the performance of the network, if the miner supply economy is at all matured at that point

It isn't something I've seen addressed on the Wiki article listing weaknesses:
 - http://en.bitcoin.it/wiki/Weaknesses

Are these, or any other changes, worth fighting for? And that is the reason for this discussion.

Fair enough, I'm personally not convinced but I'm not a dev for this project.  It is possible that no devs are following this thread here in this forum.  You could instead try adding this to the Weaknesses article, or perhaps you create an issue in github and tag it as a feature.

[luxgladius]

Fair enough, I'm personally not convinced but I'm not a dev for this project.  It is possible that no devs are following this thread here in this forum.  You could instead try adding this to the Weaknesses article, or perhaps you create an issue in github and tag it as a feature.

Well, I think the best step is to post in the dev forum in order that a discussion might be had, but for some reason, I'm still limited here, though I think I've met the requirements for getting out. Oh well, I'll wait a bit.

[philipp]

With that drop, it's hard to imagine a substantial fraction not taking their machines offline and scaling down.

I don't think so. Taking the machines offline only saves power. Continuing to operate might still be more profitable than trying to sell their mining rigs.

Philipp

[k]

I was looking for this topic yesterday but the search function is not the best. It may have some discussion of interest.
http://forum.bitcoin.org/index.php?topic=7496.0

[luxgladius]

With that drop, it's hard to imagine a substantial fraction not taking their machines offline and scaling down.

I don't think so. Taking the machines offline only saves power. Continuing to operate might still be more profitable than trying to sell their mining rigs.

Philipp

Well, as I said, I'm assuming the miner supply side will reach economic equilibrium in the next year and a half. This means that the cost to run a rig would be just under the revenue from the Bitcoins generated in doing so, in the aggregate. Power is a real cost after all. Therefore, dropping the Bitcoins generated by essentially half will cause the rigs to become unprofitable.

I was looking for this topic yesterday but the search function is not the best. It may have some discussion of interest.
http://forum.bitcoin.org/index.php?topic=7496.0

Many thanks, Kirian! As soon as I am able, I will see if I can revive that thread.

[BeeCee1]

3.  the two week difficulty reset.

Well, it's clear that the difficulty has to be adjusted in some way with some statistical significance, so I don't see the 2016 block reset as a major concern. What are your issues with it? Too long and jumpy? I guess a 1008 block size would still be fine, and if the blocks were reduced in difficulty, as above,  they could still be calculated with the same statistical significance in much lower time so that would be another advantage. Of course, the optimum would probably be some kind of Kalman filter where the difficulty is updated with every block, but I think it's actually a good idea to keep the implementation simple so less is likely to go wrong.

The OP said: "some of his coding seems ad hoc and arbitrary"  The choice of 2016 instead of some other number appears to be arbitrary.  You also seem to agree with me, sayng "I guess a 1008 block size would still be fine".

[luxgladius]

3.  the two week difficulty reset.

Well, it's clear that the difficulty has to be adjusted in some way with some statistical significance, so I don't see the 2016 block reset as a major concern. What are your issues with it? Too long and jumpy? I guess a 1008 block size would still be fine, and if the blocks were reduced in difficulty, as above,  they could still be calculated with the same statistical significance in much lower time so that would be another advantage. Of course, the optimum would probably be some kind of Kalman filter where the difficulty is updated with every block, but I think it's actually a good idea to keep the implementation simple so less is likely to go wrong.

The OP said: "some of his coding seems ad hoc and arbitrary"  The choice of 2016 instead of some other number appears to be arbitrary.  You also seem to agree with me, sayng "I guess a 1008 block size would still be fine".

Sure, I was just interested in hearing your reasons and whatever suggestions you might have for an alternative duration or even another method of adjusting difficulty.