If you dive into Satoshi Nakamoto’s writings like I have, you’ll quickly discover that his (their?) original vision for Bitcoin was that the network be available as a permission-less, peer-to-peer payment system intended for anyone, anywhere, anytime. And yes, that includes billions of disenfranchised people currently without the ability or opportunity to open a bank account.
In order for Bitcoin to scale to accommodate billions of daily users, the maximum block size currently burned into the network protocol must be increased from the paltry 1 megabyte size that’s been in effect since the birth of bitcoin way back in 2009.
Before disappearing into the ether, Satoshi foresaw the potential growth of bitcoin and had these words to say about the maximum block size:
The bitcoin core software development team, most of whom are employed by the for-profit company Blockstream, have hijacked Satoshi’s vision by steadfastly refusing to increase the bitcoin on-chain maximum block size beyond 1 megabyte.
Assuming 200 bytes per transaction, each 1 MB bitcoin block can hold a up to 5000 transactions. Since blocks are validated at 10 minute intervals, that means the network capacity is currently capped at a measly 8 transactions per second (versus Visa/PayPal capacities of hundreds of thousands of transactions/sec).
A quick glance at the home page of Blockchain.info shows that every block is full and confirmations are taking much longer than 10 minutes.
With more and more transactions competing to be added to each block, the per transaction miner’s fee, which originally amounted to pennies, is increasing at such at rate that only large transactions will make economic sense in the near future. In the worse case, people might as well quit trying to enter the Bitcoin ecosystem and revert back to using dinosaur remittance providers like Western Union at 20% per transaction.
As new individual users and businesses attempt to experiment with bitcoin, many of them are not only being turned off by larger and larger transaction fees, they’re increasingly getting annoyed by long confirmation delays – even to the point of having their transactions dropped from the network altogether because of overcapacity at peak usage times.
Of course, the bitcoin core development team (which may as well be called Adam Bach’s Blockstream Inc. team) has a billion technical excuses for keeping the max block size at 1MB, all of which have been debunked by the pro-increase-in-block-size technical community. Everyone knows the real motivation behind core’s uncompromising position: Blockstream’s plan to profit from the side chain products they are developing.
Speaking of the pro-increase-in-block-size technical community, they are on their third valiant try at attempting to put Bitcoin back on track with Satoshi’s original vision:
To hell with the Bitcoin core development team’s self-serving roadmap for Bitcoin, I support Bitcoin Unlimited. So should you.
I’m a long time C++ programmer who’s going to expose something embarrassing about myself. As a starting point, please take a look at the code below:
The first std::cout statement prints out the letter A and the second one prints out B. Here comes the embarrassing part… I erroneously thought that both the map::insert() and map::operator functions expressed the same semantics:
If the map object already contains an entry for the key being supplied by the user in the function call, the value supplied by the user will not be copied into the map.
Applied to the specific example above, before running the program I thought both std::cout statements would print the letter A.
Of course, as any experienced C++ programmer knows (or, in my case, should know), this behavior is only true for the map::insert() function. The map::operator function combined with the assignment operator will always copy the value into the map – regardless of whether or not an entry for the key is already present in the map. It makes sense that the two functions behave differently because sometimes you want an unconditional copy and sometimes you don’t.
The reason I wrote this post is because I very recently got burned by my incorrect assumption. To make a long story short, there was a bug in my large program that eventually was traced, with the help of the simple code example above, to the bad line of code that I wrote using map::operator. A simple change to map::insert() fixed the bug. It was critical to the application that an existing value in the map not be overwritten.
One of the dings against C++ is that it contains a lot of subtle, quirky semantics that are difficult for mere humans to remember. Despite agreeing with this, I still love the ole language that keeps on chugging forward like the little train that could (direct mapping to the hardware and zero overhead abstraction), despite the chagrin of many in the software industry:
- The U.S. government may be considering taking the $100 bill out of circulation.
- The E.U. is scrapping the $500 euro note.
- India is recalling the 500 and 1000 rupee notes.
- 900 of Sweden’s 1,600 bank branches no longer keep cash on hand or take cash deposits.
The war on cash is in full swing and while the banks are, as usual, winning, the citizenry is losing money and privacy. As physical transactions with cash decrease, electronic transactions with plastic increase, which means that more transaction fees get collected and the banks get richer. In addition, since every transaction is electronically recorded, your privacy can get hacked by criminals and/or your “friendly” government.
The only way I know of for the average Joe Schmoe to fight back is for him to buy, and personally take possession of, precious metals and cryptocurrencies like bitcoin. Taking physical possession of your property is crucial because any asset that you own which resides in an entry on a centralized institutional ledger can be confiscated or frozen by your government in times of a crisis of their own making – even if you are a hard-working, law-abiding, citizen.
Regarding the precious metals and cryptocurrencies, taking possession of, and storing, a physical precious metal is much more costly/risky than doing the same for a virtual cryptocurrency. The larger the amount, the more costly/risky it is….
Ah yes, one more thing about precious metals, specifically gold. The government can unconditionally ban the possession of physical gold and demand its return to the US government. It actually has done this before. In 1933, F. D. R. issued executive order 6102, which forbade:
Notice the use of the word “hoarding” – as if trying to protect your hard earned property from seizure is a bad, immoral, thing.
In the future, governments can forbid the “hoarding” of cryptocurrencies. However, since decentralized networks cannot be shutdown and private keys can be stored on tiny devices, large scale enforcement would be next to impossible.
In 1998, the U.S. treasury and the federal reserve facilitated a $3.6B bailout of the Long Term Capital Management Fund (LTCM) hedge fund by 16 Wall St. banks. No taxpayer funds were used in the bailout.
Ten years later, in 2008, the U.S. treasury bailed out a slew of Wall St. institutions with 100s of billions of dollars in U.S. taxpayer money.
Famous doom-and-gloomers James Rickards and Peter Schiff predict that the next financial crisis, which will be the mother of all global fiscal catastrophes, will require that the U.S. government be bailed out by the International Monetary Fund. In this black swan scenario, the U.S. dollar will be replaced by the IMF’s SDR (Special Drawing Rights) as the world’s reserve currency and America’s reign as the world’s greatest superpower will come to an end.
I’m not convinced that Rickards and Schiff are right, but they do make a somewhat compelling case – enough so that it makes me feel “uncomfortable” whenever I see or hear them speak about it. Even if you think they are both batshit crazy, you might want to think of adding a touch of gold, silver, Bitcoin, or some other cryptocurrency to your portfolio…. just in case America fails to become great again.
Assume that you’re actively working on a successful software development project before the Agile manifesto was created/signed and before Scrum was formally defined by Sutherland/Schwaber. The timeline and parameters of your project may look like this:
The number of managers and developers involved in the day-to-day work is most likely fixed and no executives directly meddle with the team’s internal affairs. In addition, the average number of hours worked per week per team member and the average stress level felt by the team is most likely constant. Most importantly, status reviews aren’t conducted on a daily basis. Once or twice a week is the norm. Because of the lack of a mandated daily status meeting, some healthy slack is available to the team for learning and doing things directly applicable to the project but not enumerated on the schedule/backlog. All is well, a healthy and sustainable pace is being maintained.
Now, imagine that at some point in the future of the project, someone in the executive suite decides (either rationally o irrationally) that the project is either behind schedule or over budget or, most likely, both. When that fateful day arrives, you will be suddenly transported into…. The Micromanagement Zone (TMZ):
The project timeline will most likely transition to this:
The consequences of transitioning into TMZ are never good for anyone involved (developers, managers, executives, customers):
- The frequency of status meetings will rise – most likely to at least one per day.
- The number of managers assigned to “oversee” the project will rise.
- One or more executives will get intimately involved in the day-to-day execution of the project.
- Some additional number of newbie developers may be suddenly injected into the team, bringing progress to a crawl.
- The number of hours worked per week per developer will rise.
- “Sustainable pace” will never be uttered again. The workaholics on the team will brag about toiling late into the night and on weekends.
- The average stress level will rise and the average physical health of the team will deteriorate.
The worst thing about entering TMZ is that it’s like a black hole: once you’re in, you can never escape. Well, that’s not quite true. You can leave of your own free will or the project may get cancelled.
So, how does Agile and/or Scrum solve this stubbornly entrenched and globally ubiquitous MZ problem? It doesn’t. In fact, every Agile/Scrum project is poised from the get-go to glide into the MZ as soon as the project is “deemed in trouble“. The fact that daily status meetings (promoted innocently in the Agile world as informally loose “standup” meetings) are required from day one points every Agile project directly toward the MZ abyss – all signed up and ready to jump. In the pre-agile days, daily status meetings were only initiated after the project was deemed in trouble, they weren’t required from day one.
The agile folks will say that the purpose of the daily standup meeting is to provide early warning detection of a project that is heading for trouble – and they can be right. They’ll also say that early detection will allow actions to be taken to get the project back on track – and they can be right. However, the specific “actions” taken to reign in the project may actually be those that will thrust the project squarely into the MZ .
I haven’t ranted against the software con$ultant industry in a while, so I decided that now is as good as ever to do it again. To that end, I submit Twitter exhibit A to the jury:
I guess that “explaining” how to do a stand up meeting to executives in which 3 simple questions are asked/answered only takes 5 minutes, but “training” them how to do it takes an intensive, four day on-site course at $2K per day… plus expenses.
As a general observation, consultants love to make the obvious and mundane look like a complicated and unfathomable hairball that only they can unravel for you, at a “fair” price.