Author Archive

The Road To Here

October 13, 2015 Leave a comment

Having jumped into the world of Bitcoin investment, I recently reflected on how I was bitten by the BTC bug and influenced into making the decision to buy and hold some BTC. So I pieced together the following timeline of events on how I got to here:


My random road to BTC investment reminds me of the speech that Steve Jobs gave at the 2005 Stanford University commencement ceremony. He told of how his learnings in multiple, seemingly unrelated, topic areas led to the serendipitous creation of the revolutionary MacIntosh computer.


By a large margin, the Wences Cesares interview had the greatest impact on my decision to invest in Bitcoin. Incredibly, Wences mentioned Graeber’s book on debt, which I had read before I even knew what Bitcoin was. He also told his story of growing up in Argentina and how his family lost everything they owned multiple times because of rampant inflation due to incompetent government handling of the Argentinian peso. In the worst of times, whenever his family received a paycheck they would rush to the store and buy as much food as they could before prices increased – sometimes on an hourly basis. As they were putting items in their shopping cart, store employees were simultaneously walking down the aisles with their pricing guns and jacking up the prices.

We fat cats in the US and other relatively stable financial environments can’t relate much to the wildly volatile living conditions in Argentina and other countries in the same rickety boat. However, as the near financial meltdown in 2008 hinted at, we might not be as insulated from a catastrophic black swan financial event as our so-called leaders imply we are.

The bitcoin economy may collapse and my investment in BTC may end up dropping to zero, but since I’m adhering somewhat to Taleb’s 80-20 investment guidance, it won’t put me out on the streets begging for food if it does. In the best case, the BTC/USD price ratio will keep steadily rising and BTC’s price volatility will decrease over time. If those trends come to pass, then I win and unfortunate people in countries run by bozos have a chance of winning too. For them, BTC may become a stable hedge to insulate their accumulated wealth against crash-pron fiat currencies issued by their irresponsible governments.

It’s A Governance Issue

October 10, 2015 Leave a comment

The “blockchain” is the heart of the Bitcoin system. It’s a fully transparent, publicly visible, ledger of every transaction ever performed over the network. Approximately every 10 minutes, a new block of verified BTC transactions is added to the blockchain by a “miner“.


The figure below shows a simplified view of the BTC blockchain. As you can see, the system’s current design parameters only support a throughput rate of less than 10 Transactions Per Second (TPS).


If the usage of Bitcoin as a secure, decentralized, private, payment system continues to grow, the low TPS rate will become a bottleneck if the system doesn’t scale to accommodate the increased load on the network.

Two obviously simple ways for increasing the Bitcoin system throughput are to:

  • increase the maximum block size, S
  • decrease the block addition period, T

A major bone of contention in the Bitcoin community is how to scale the TPS rate to accommodate the anticipated growth in usage due to more and more people “discovering” the benefits of this peer-to-peer cash system over traditional banking systems of dubious credibility. This “block size” debate has been raging on for 2 years now. There are a range of proposals in play for solving the scaling problem; some are dirt simple and some are mind-boggling complex.

Resolving the dispute is exacerbated by the fact that, by design, there is no central authority controlling the system’s evolution. It’s a governance issue not dissimilar from growing a “flat” startup company into a hierarchical, “mature” organization. If a centralized authority with control over the evolution of the Bitcoin protocol is established, the doors will burst wide open for political intrigue and clever, special interest group agendas to infiltrate the currently egalitarian system.



Categories: bitcoin Tags: ,

Stack, Heap, Pool: The Prequel

October 7, 2015 Leave a comment

Out of the 1600+ posts I’ve written for this blog over the past 6 years, the “Stack, Heap, Pool” C++ post has gotten the most views out of the bunch. However, since I did not state my motive for writing the post, I think it caused some people to misinterpret the post’s intent. Thus, the purpose of this post is to close that gap of understanding by writing the intro to that post that I should have written. So, here goes…

The figure below shows a “target” entering, traversing, and exiting a pre-defined sensor coverage volume.


From a software perspective:

  1. A track data block that represents the real world target must be created upon detection and entry into the coverage volume.
  2. The track’s data must be maintained in memory and updated during its journey through the coverage volume. (Thus, the system is stateful at the application layer by necessity.)
  3. Since the data becomes stale and useless to system users after the target it represents leaves the coverage volume, the track data block must be destroyed upon exit (or some time thereafter).

Now imagine a system operating 24 X 7 with thousands of targets traversing through the coverage volume over time. If the third processing step (controlled garbage collection) is not performed continuously during runtime, then the system has a memory leak. At some point after bootup, the system will eventually come to a crawl as the software consumes all the internal RAM and starts thrashing from swapping virtual memory to/from off-processor, mechanical, disk storage.

In C++, there are two ways of dynamically creating/destroying objects during runtime:

  1. Allocating/deallocating objects directly from the heap using standard language facilities (new+delete (don’t do this unless you’re stuck in C++98/03 land!!!), std::make_shared, or, preferably, std::make_unique)
  2. Acquiring/releasing objects indirectly from the heap using a pool of memory that is pre-allocated from said heap every time the system boots up.

Since the object’s data fields must be initialized in both techniques, initialization time isn’t a factor in determining which method is “faster“. Finding a block of memory the size of a track object is the determining factor.


As the measurements I made in the “Stack, Heap, Pool” post have demonstrated, the pool “won” the performance duel over direct heap allocation in this case because it has the advantage that all of its entries are the exact same size of a track object. Since the heap is more general purpose than a pool, the use of an explicit or implicit “new” will generally make finding an appropriately sized chunk of memory in a potentially fragmented heap more time consuming than finding one in a finite, fixed-object-size, pool. However, the increased allocation speed that a pool provides over direct heap access comes with a cost. If the number of track objects pre-allocated on startup is less than the peak number of targets expected to be simultaneously present in the coverage volume at any one instant, then newly detected targets will be discarded because they can’t “fit” into the system – and that’s a really bad event when users are observing and directing traffic in the coverage volume. There is no such thing as a free lunch.


What’s In Your Wallet(s)?

October 4, 2015 Leave a comment

My Bitcoin iPhone Wallets

Since I’m a nouveau BTC investor, I downloaded a bunch of free Bitcoin apps onto my iPhone:

btc apps

Out of those nine apps, four of them are “on-device” wallets: bitWallet, BlockChain, bread, and Airbitz. Two of the apps, Coinbase and Xapo, allow me to connect to my online accounts at those two major, reputable, Bitcoin currency exchanges. The remaining three apps are for keeping up with the latest BTC news and Blockchain statistics/metrics.

Inter-Wallet Transactions

PC To iPhone

The following figure shows the home screen of my iPhone Blockchain wallet app at the time of this writing.  To test out and evaluate the wallet’s feature set and UI, I sent approximately $13 USD worth of BTC from one of my PC wallets  to my Blockchain app wallet. As you can see, the bottom transaction shows the reception of $13.27 USD worth of BTC at my Blockchain wallet’s public address (1Ni….vvC).


I  executed this PC-to-iPhone, inter-wallet, transaction by:

  1. Copying and pasting my Blockchain wallet receive address into an e-mail and sending the e-mail from my iPhone to my account.
  2. Opening the e-mail on my PC and copying/pasting the address into one of my PC wallets (Bitcoin Core).
  3. Initiating a “send BTC” transaction from my PC wallet back to my iPhone Blockchain wallet.

PC to iphone

iPhone To Web

The top transaction on the Blockchain home screen shows that I subsequently sent $1.00 USD (with a 2 cent transaction fee to the miner who successfully added the block containing my transaction to the BTC blockchain) from my iPhone to another BTC wallet whose public receive address is 1H….kx1L. That destination wallet happened to be associated my account on the web site.

I  executed the iPhone-to-Web, inter-wallet, transaction by:

  1. Copying and pasting my wallet receive address into an e-mail on my PC and sending the e-mail to my account.
  2. Opening the e-mail on my iPhone and copying/pasting the address into my iPhone Blockchain wallet.
  3. Initiating a “send BTC” transaction from my iPhone wallet to my wallet.

PC to iphone to web

There is an alternative, perhaps even easier way to send/receive Bitcoins than copying/pasting long addresses to/from your device/PC clipboard. You can use a wallet-generated QR code in conjunction with your device camera.

The figure below shows the QR code graphic associated with one of the Bitcoin receive addresses (1A8…GDqT) on my iPhone Blockchain wallet. If you wanted to send some bitcoin to an address represented by a QR code, you’d:

  1. Open up your wallet app (PC, iPhone, or web),
  2. Instruct the app to scan the QR code of the destination address,
  3. Enter the amount of BTC or USD you want to send,
  4. Initiate the transaction.

You can try scanning the QR code below and sending me some bitcoin if you’d like :)

qr code

Citizen To Citizen, Phone To Phone

Assuming that the BTC economy doesn’t implode due to a black swan event and the “permission-less innovation” that the decentralized platform provided by the bitcoin protocol keeps the technology progressing forward, the user experience will only improve with time.

As long as smartphone prices keep decreasing and incompetent central governments keep consistently debasing their currencies (Argentina, Venezuela, Zimbabwe, Cyrus, Greece, etc), most of the world’s population might soon be executing inter-wallet BTC transactions for goods and services using a process similar to the experimental ones I described in this post – especially phone-to-phone transactions (no PC ownership or web access required).

Exchanging BTC for common goods and services may never take hold in advanced countries with stable currencies like the USA, but most of the globe may be ripe for the taking. What do you think?


Categories: bitcoin Tags: , ,

Me, The Banker, And You

October 1, 2015 2 comments

Me, the banker, and you, before Bitcoin:


Me and you, after Bitcoin:


People who have experimented with Bitcoin can relate to this cartoon. People who haven’t, can’t; it’s simply too alien for them.

And yes, that pic on the “right” is intended to represent you, Phil :)

Categories: bitcoin Tags:

The Problem, The Culprits, The Hope

September 28, 2015 14 comments

The Problem

Bjarne Stroustrup’s keynote speech at CppCon 2015 was all about writing good C++11/14 code. Although “modern” C++ compilers have been in wide circulation for four years, Bjarne still sees:


I’m not an elite, C++ committee-worthy, programmer, but I can relate to Bjarne’s frustration. Some time ago, I stumbled upon this code during a code review:

class Thing{};
std::vector<Thing> things{};
const int NUM_THINGS{2000}; 
for(int i=0; i<NUM_THINGS; ++i) 
  things.push_back(*(new Thing{})); 

Upon seeing the naked “new“, I searched for a matching loop of “delete“s. Since I did not find one, I ran valgrind on the executable. Sure enough, valgrind found the memory leak. I flagged the code as having a memory leak and suggested this as a less error-prone substitution:

class Thing{};
std::vector<Thing> things{};
const int NUM_THINGS{2000}; 
for(int i=0; i<NUM_THINGS; ++i) 

Another programmer suggested an even better, loopless, alternative:

class Thing{};
std::vector<Thing> things{};
const int NUM_THINGS{2000}; 

Sadly, the author blew off the suggestions and said that he would add the loop of “delete“s to plug the memory leak.

The Culprits

A key culprit in keeping the nasty list of bad programming habits alive and kicking is that…

Confused, backwards-looking teaching is (still) a big problem – Bjarne Stroustrup

Perhaps an even more powerful force keeping the status quo in place is that some (many?) companies simply don’t invest in their employees. In the name of fierce competition and the never-ending quest to increase productivity (while keeping wages flat so that executive bonuses can be doled out for meeting arbitrary numbers), these 20th-century-thinking dinosaurs micro-manage their employees into cranking out code 8+ hours a day while expecting the workforce to improve on their own time.

The Hope

In an attempt to sincerely help the C++ community of over 4M programmers overcome these deeply ingrained, unsafe programming habits, Mr. Stroustrup’s whole talk was about introducing and explaining the “CPP Core Guidelines” (CGC) document and the “Guidelines Support Library” (GSL). In a powerful one-two punch, Herb Sutter followed up the next day with another keynote focused on the CGC/GSL.

The CGC is an open source repository currently available on GitHub. And as with all open source projects, it is a work in progress. The guidelines were hoisted onto GitHub to kickstart the transformation from obsolete to modern programming.

The guidelines are focused on relatively higher-level issues, such as interfaces, resource management, memory management, and concurrency. Such rules affect application architecture and library design. Following the rules will lead to code that is statically type safe, has no resource leaks, and catches many more programming logic errors than is common in code today. And it will run fast – you can afford to do things right. We are less concerned with low-level issues, such as naming conventions and indentation style. However, no topic that can help a programmer is out of bounds.

It’s a noble and great goal that Bjarne et al are striving for, but as the old saying goes, “you can lead a horse to water, but you can’t make him drink“. In the worst case, the water is there for the taking, but you can’t even find anyone to lead the horse to the oasis. Nevertheless, with the introduction of the CGC, we at least have a puddle of water in place. Over time, the open source community will grow this puddle into a lake.


A Daunting List

September 25, 2015 Leave a comment

In “The Ultimate Guide to Bitcoin“, Michael Miller provides us with a daunting list of the risks associated with Bitcoin:


For BD00, the biggest existential risk on the list is “Powerful People Don’t Like It“. It’s also one of the top reasons he is into Bitcoin for the long haul. How about you?

BTCWillNot Stand

Categories: bitcoin Tags:

Get every new post delivered to your Inbox.

Join 573 other followers

%d bloggers like this: