I saw a fantastic video online the other day on Hamming codes, and gotta say — exceptionally bad-ass as well!
To put It in economic terms, an economy based on bitcoin would be inherently deflationary. People would spend less in anticipation of the value of their money going up in value.
So rather than more money leading to Inflation and rising prices (with some caveats), you would have falling prices in general as bitcoin is hoarded and the money supply.
Having generally falling prices sounds good but is actually a horrible economic situation. Typically debts don’t fall while the price of goods and services you are selling to pay such debt does.
Thanks! What’s the net effect for a sub-economy that’s deflationary, given that it’s a subset of a larger economy that’s generally inflationary? What does the long-term future of bitcoin look like under my analysis given that we also have, you know, actual currency?
Good question and a couple of thoughts come to mind.
First, I would argue we already have segments of the economy that are deflationary where the prices of certain things are falling while others are rising (I.e., some manufactured goods(falling) vs healthcare(rising)).
Longer term for bitcoin or other crypto currencies, I don’t see it catching on as a medium of exchange because people will be reluctant to spend something that is going up in value compared to paper money or credit/debit cards. So it’s only monetary use is a possible store of value like gold. Gold has storage and transaction costs which may be comparable to and possibly cheaper than blockchain‘s energy costs. So I don’t see it lasting.
(This is not investment advice, just my take. People can and will gain and lose money with cryptocurrencies.)
And full disclosure, I own a little stock in a bitcoin miner trying to profit off the mania. And on further thought I will probably sell in thinking about the social and environmental costs.
I worked for a blockchain startup that was not doing cryptocurrencies, and they had a good pitch (enough to get me to join (plus a sweet salary)).
Their pitch was a lie. They had “blockchain technology” but it was actually being used as a really slow and limited database; there was no distributed access (all interaction was through their APIs) and no plans to change that.
I ultimately was forced out because of questioning their approach. I think in the end it was a kind of pump and dump to feed off of all that VC money looking for love.
I learned enough about how to build a real blockchain solution but I’ve yet to find a real-world use case that would truly benefit from it.
I accept the veracity of this anecdote … primarily because of the properly matched parentheses.
ReplyAll did a story on this recently. They interviewed a guy who tracks down BitCoin for a living, and it’s apparently not that difficult to deduce who people are from the transaction history. Anonymous in principle, maybe, but not in practice.
Sometimes it is even worse than that- it starts to flirt with religion. I work at a “big data” company, and daily I watch people assume that applying enough machine learning to terrible noisy data will somehow make it useful signal. People are then making million-dollar decisions based on this. Just because there are numbers, people think the information is real, but it’s just useless noise that has been pumped through a transformation that nobody understands and comes out the other side as different noise.
As a computer scientist, the whole thing makes me very uncomfortable. ML has done great things for speech recognition and other a few other fields, but when it starts getting applied to very weak medical sensors, election demographics, and other bad data sets, the hair on my neck stands up.
I think there’s a serious dose of engineer hubris here too. Can’t help thinking of that classic XKCD:
They were using Hyperledger Fabric, but as a black box, fronted by a mysql database. Everything came into mysql, and they had a microservice to handle replication to Fabric, because when used directly it ran at a couple transactions per second. This had been built by a team at a technical school in a third world country and had been inherited by the current engineering staff, which had basically polished this turdball so that it had lots of unit tests and support tooling. An extreme case of cargo-cult engineering.
It didn’t take me long to determine the reason was because they had multiple sessions trying to update the same value, and you can only do that once per block. By restructuring the data and access patterns I was able to get them up to the edge of what was feasible with Fabric.
They then took that design and re-built the original system, but with a different database system. It burns me to this day.
Was there redis in there somewhere?
In my design, yes
At its core, Fabric is a K/V store that allows for atomic transactions, in that a block can set multiple K/V pairs, but guarantee that each key is only modified for that transaction (block).
I changed their black box into a K/V interface and added a caching interface that could use Redis or its cloud equivalent. Stupid simple, but I’m just a simple code monkey.
I understand the lure of shiny but I think Redis belongs in the “this shit works” toolbox.
When used as a simple cache I suppose it is, but my experience is with a project where the developers seemed to want to use it as a relational database, and it was a huge CPU and memory hog. I re-engineered the system with python, django and mysql, and it runs much better.
Understood. In this case they had a hardon for couchbase.
I had a default in memory cache (map+mutex in Go) and it was decent at that. The notion I had for Redis was to have a shared cache to avoid localization. I never got the chance to properly try it out because they were busy rebuilding the mysql functionality in couchbase.
I have my biases (including a weakness for SQLite), but I try my damndest to let the nature of the problem dictate the correct tools to solve it.
Nobody’s yet mentioned the #1 real good-time application of blockchain: Virtual Cats
I thought those were really not-cryptocoins for places that outlawed cryptocoins?
Freaky but intriguing – RedBeardLab/rediSQL (on github)
I haven’t heard that. I just saw it as a way to entice money (or ETH) out of people’s pockets.
I’ve watched Bitcoin – with increasingly raised eyebrows – for a decade. Initially I was attracted by its decentralized audacity, mathematical cleverness and cyberpunk-like back story. As it exploded though, I shied away from buying any as it just felt unreal. Bitcoin’s only visible impact in my immediate world was an inability to buy a decent graphics card for my work. To me, cryptocurrency has always looked like pure speculation without any utility.
Maybe six months ago though, I stumbled on Helium, a distributed network to support low-power low-bandwidth communication (think sensors, asset tracking, etc.). Rather than proof-of-work, currency would be earned by providing proof-of-coverage. On the use side, data credits could be purchased in this currency to allow communication without having to have, for example, a telco account for each device. My hotspot has been running now for a couple of months, providing overlap coverage in downtown Vancouver. At the moment there is very little actual sensor data going through my hotspot - its mostly proof-of-coverage challenges and witnesses. However, given that this network supports existing LoRa sensors, once coverage expands a bit more, I’m hoping to see it used for real applications. (I have a tag that I’ve been carrying around to test with. The tag tracks reliably and I’ve spent an inordinate amount of time digging through its history in the blockchain explorer.) As someone who has been extorted by telcos wanting $15/month to track an asset, I think this is a cool technology.
(Disclaimer. Though it wasn’t my reason for buying a hotspot, I potentially stand to profit from increased use of Helium.)
Super tangential observation. As a former coder the US English style of including sentence-terminating periods inside quotation marks kills me, that shouldn’t parse. But, I agree about “properly matched parentheses.”