Bitcoin In UML
Abstraction Is Selective Ignorance – Andrew Koenig
All Models Are Wrong, Some Are Useful – George Box
The following figure attempts to show the relationships between major Bitcoin system entities as captured in a UML class diagram .
Starting from the bottom of the diagram, a Bitcoin user can own zero or more Hardware, Web, Mobile, PC, and/or Paper Wallets. Each type of Wallet is a Bitcoin node. A Miner is also a BTC network node. Each BTC node establishes a one-to-many relationship with other peer BTC nodes connected to the network.
An alternative UML structural “view” of the BTC system is given as:
Each BTC node retains a copy of the global, publicly shared Blockchain. As of this writing, the Blockchain has 380K+ Blocks. Each Block has one or more validated BTC Transactions embedded within it. Via the interface facilities provided by a BTC Node, a User composes a Transaction and submits it to the network for validation and execution. Each instance of a BTC Transaction contains a source address, destination address, the BTC amount to be transacted, and the source address owner’s signature.
The Blockchain Without The Bitcoin
If you read the financial press, you’ll see a lot of mentions of “blockchain technology” without any mention of Bitcoin. That’s because your friendly banksta (you know, the one who: almost blew up the world in 2008, never went to jail, and was bailed out with your and my money) wants the blockchain without the Bitcoin.
Bitcoin is an existential threat to the banking mafioso, but blockchain technology without the Bitcoin can save the Bankstas tons of money by allowing them to fire lots of accounting employees. Of course, if the Bankstas succeed in incorporating blockchain technology into their operations, dollars-to-donuts says they won’t pass on the cost savings to you and me; they’ll just write bigger bonus checks to themselves and their myriad of vice-presidents. Trickle down economics never worked before, and it won’t work now.
Which system do you think is better for average Joe’s like you and me: one with a decentralized, publicly scrutable blockchain, or the Banksta’s alternative; a proprietary blockchain hidden behind a centralized “just trust me” coalition of fee-obsessed banks?
A Sweet Gig
Because of my new found interest in Bitcoin, I started poking into the structure of the US federal reserve system. Directly from the Fed’s website, I snipped this interesting answer to a FAQ on ownership:
So, let me get this straight. The Fed is a non-profit seeking org, but it is owned by profit-seeking orgs (commercial banks). But why would a profit-seeking org want to own a non-profit seeking org?
Ah hah, the second, circled, text fragment yields the answer: the profit-seeking orgs who own the non-profit seeking org are guaranteed by law to receive a yearly, risk-free, dividend of 6%.
Unless I’m missing something big (and I might be since I’m quite the simpleton), the banksters have quite the sweet gig goin’ on here. Especially when dividend yields on short term US treasuries available to average Joe Schmoes like me and you are hoovering close to zero percent. I’d be thrilled to receive a guaranteed, risk-free, 6% annual yield on any bonds/notes that I own. Wouldn’t you?
The least our lawmakers could do is tie the yield paid out to the Fed’s owners to the yield on one year treasury notes, no? But I doubt that can or will happen; not while the fox is guarding the hen house.
As I learn more and more about how the current, centralized, financial system operates, I become more enthusiastic about the prospects of Bitcoin to: disrupt the status quo, cut out the middlemen, and weaken the fat cat institutions that are reaping big rewards from their system without having to place any skin in the game.
Gold, Currency, Bitcoin
The diagram below shows some important attributes of a good “currency of exchange” and “store of value“; in other words, a good “money“. The most important characteristic is that people perceive the artifact that represents money as valuable. The second most important attribute, but not independent of the first, is scarcity. When fiat currencies collapse and lose their value, it’s because governments have printed too much of it (to finance wars and massive, unsustainable social programs). It ceases to be scarce and its holders lose faith in its value.
Gold and other precious metals serve as a good store of value and a hedge against volatile currencies because it is scarce. However, gold is not a very good, practical, currency of exchange because it’s not very portable in large amounts (armed guards, armored vehicles) or accurately divisible. That’s why you don’t see Amazon.com or Target accepting gold for their products, or governments accepting gold bars/nuggets as payment for taxes.
Physical, difficult-to-counterfeit, paper dollars and coins serve as a good medium of exchange because of their increased portability, fungibility, and divisibility relative to gold. Dollars can also serve as a good store of value as long as their issuer doesn’t go wild and turn the dials up to 10 on their mints – which is ominously becoming more common nowadays.
Theoretically, secure virtual currencies like Bitcoin trump gold and cash in all categories except for one.
- BTC is guaranteed to be scarce since there is no way to mint more than 21M BTC – this limit was baked into the system since day one by system designer Satoshi Nakamoto.
- BTC is portable because it weighs nothing – a BTC is simply a number in a disk file that can be transferred securely and speedily over the internet at will by its owner (with no middle parties taking a cut or delaying the transfer).
- BTC is fungible because it can’t be counterfeited. The huge amount of crypto computing power underlying the system ensures that double-spending is astronomically impossible.
- BTC is divisible down to .00000001 of 1 BTC, or 1 “satoshi”. When the BTC mint shuts down sometime in 2140, 1 X 10**14 satoshis will be in circulation and virtual vaults throughout the world.
The sole category where Bitcoin doesn’t trump gold/cash is in social consensus of perceived value. The vast majority of the 7 billion people in the world perceive the value of BTC to be zero.
As I write this post, the handful of millions of people who transact in Bitcoin (i.e. the market) “perceive” 1 BTC to be worth $200+ in cash issued by the most financially viable country on the globe – the USA. But alas, if the market turns, Bitcoin’s value might revert back to the value it was born with: zero.
The Road To Here
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-prone fiat currencies issued by their irresponsible governments.
It’s A Governance Issue
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.
Stack, Heap, Pool: The Prequel
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:
- A track data block that represents the real world target must be created upon detection and entry into the coverage volume.
- 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.)
- 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:
- 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)
- 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)?
My Bitcoin iPhone Wallets
Since I’m a nouveau BTC investor, I downloaded a bunch of free Bitcoin apps onto my iPhone:
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:
- Copying and pasting my Blockchain wallet receive address into an e-mail and sending the e-mail from my iPhone to my account.
- Opening the e-mail on my PC and copying/pasting the address into one of my PC wallets (Bitcoin Core).
- Initiating a “send BTC” transaction from my PC wallet back to my iPhone Blockchain wallet.
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 Coinbase.com web site.
I executed the iPhone-to-Web, inter-wallet, transaction by:
- Copying and pasting my Coinbase.com wallet receive address into an e-mail on my PC and sending the e-mail to my account.
- Opening the e-mail on my iPhone and copying/pasting the address into my iPhone Blockchain wallet.
- Initiating a “send BTC” transaction from my iPhone wallet to my Coinbase.com wallet.
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:
- Open up your wallet app (PC, iPhone, or web),
- Instruct the app to scan the QR code of the destination address,
- Enter the amount of BTC or USD you want to send,
- Initiate the transaction.
You can try scanning the QR code below and sending me some bitcoin if you’d like 🙂
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?
Me, The Banker, And You
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 🙂
The Problem, The Culprits, The Hope
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)
things.push_back(Thing{});
Another programmer suggested an even better, loopless, alternative:
class Thing{};
std::vector<Thing> things{};
const int NUM_THINGS{2000};
things.resize(NUM_THINGS);
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.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 