It's not a lot by itself, of course, but I'm not going to begrudge local and state officials from exercising what powers they do have to try and make the situation a bit better.
2,000 karma · joined August 9, 2012
It's not a lot by itself, of course, but I'm not going to begrudge local and state officials from exercising what powers they do have to try and make the situation a bit better.
In practice, running a mining node without specialized equipment is prohibitively expensive so we're stuck finding a third party. Most of those third parties are looking to do a volume business and aren't interested in one-off small dollar transactions, so it's centralized exchanges or nothing.
There's always going to be niche markets for people who can't use fiat currencies for one reason or another (international commerce, failed states, black markets, etc.), and there's probably going to be some number of hobbyists who want to transact in crypto as a political or technical end in itself.
But why would the median consumer possibly want to migrate to a world where their real net worth could halve or double literally overnight, repeatedly, at any time, for reasons they can neither predict nor control?
I want this guy to be compensated, but I'd prefer this guy be compensated in a manner that doesn't prevent third parties from fixing their hardware. In general, I think bounties are a good solution to this. Failing that, there are plenty of trade groups and nonprofits and regulatory bodies that could be tasked (and funded) with acquiring and freely redistributing this class of innovation if we wanted to.
What I haven't been able to get a straight answer on is exactly which specific types of power. Because as far as I can tell, a government could still levy taxes in BTC. They could still impose whatever financial regulations they wanted on top of BTC. They couldn't force or prevent transactions, but they could still observe them and impose fines (and, ultimately, jail time or asset seizure) on entities who didn't follow the regulations. They could still demand record keeping and reporting from any businesses they wanted, and would still be able to perform audits to ensure compliance. Given that most of the blockchain implementations allow a third party to easily reconstruct transaction histories, quite a few types of regulation seem like they would actually be easier to enforce.
As far as I can tell, the only governmental function that cryptocurrencies actually disallow is central banking. That may or may not be a good thing, but either way it doesn't feel to me like a world shaking reclaiming of some fundamental liberty from the clutching tentacles of the Leviathan, and it doesn't seem like it would fundamentally alter the day-to-day experience of participating in the economy.
So, what am I missing? What should "not controlled by the government" actually imply, specifically? Or, if that's the wrong way to express the underlying sentiment, what would be a correct statement of the idea?
For example, imagine banks wanted to replace their clunky old ACH system with a blockchain. They could design their protocol such that it refuses to process transactions from or to an address that hasn't contributed a block to the chain in, say, the last 24 hours.. That requires each bank to contribute some minimum amount of computing power to maintaining the chain, even though it doesn't directly reward them for it.
(I've spent literally 2 minutes thinking through this example. I'm sure it has some glaring holes in it. Still, I hope it illustrates the point.)
The first is the blockchain, which is a technical innovation that allows a client to decide which version of a shared event log to trust, even if it doesn't trust any of the servers attempting to perform the update. The ELI5 version is that the record that took the most total work to generate is correct. Since generating a fraudulent record requires doing more total work than was done to generate the correct one from the point of the fraudulent change forward, creating a fraudulent record quickly becomes computationally infeasable as changes get older.
The second are cryptocurrencies, which are an attempt to mint a currency (a literal, if not physical, coin) independent of any government by, essentially, reintroducing the gold standard. Except instead of gold we're using blockchains, which it turns out can be engineered to behave economically like precious metals do under the right circumstances.
Separating the two concepts, and specifically avoiding putting on your engineer hat when you're thinking about the half that's more political manifesto than anything else, will go a long way in helping you get a toehold on what's going on.
I think cryptocurrencies are here to stay. I'm not convinced that's actually going to "positively affect the industry in the upcoming future".
I don't think cryptocurrencies are going to remove the need for some big middleman like Visa to sit between individual consumers and their partners. Things like reversible transactions and on-demand small loans are too attractive to the median consumer, so someone's going to be layering them on top of the underlying currency, whatever it may be.
I don't think they're going to have a big impact on the financial sector. They can trade and leverage and loan with cryptos just as easily as they can with fiats, just with a lot of the safety rails like bankruptcy pulled off.
I don't think they're going to impact most governments' ability to levy taxes and to borrow. There are dozens of governments that don't mint their own currencies, and by and large they still maintain taxing authority about as easily as they maintain the rest of their infrastructure and bureaucracy.
I do think it's going to prevent central banks from doing their thing, but I'm not convinced that's a good thing. Central banks have their issues, to be sure, but I'm pretty sure they're better than the huge boom & bust cycles they replaced.
Cryptocurrencies will certainly make the world different in meaningful ways. Different doesn't necessarily mean better.
It's called Washbox, and it's a locker in the atrium of my apartment building. I drop my clothes off, text the locker number to the company, and my clothes will be returned clean the next day. It is, in fact, both super useful and cheap.
I'm sure they would love to automate their washing & folding process further, but those implementation details are already well abstracted from me as the end user. If I were interested in automating laundry, it seems smarter to start by targeting industrial use by existing laundry services who will be willing to pay more per unit and put up with more quirks than a home user would.
Maybe Bitcoin isn't a speculation bubble; maybe it's something new. But if you ignore the underlying tech and just look at the price chart it sure looks like an old fashioned speculation bubble, and those traditionally don't end well for the median investor.
It's a natural side effect of a first-past-the-post voting system[1].
If you mean the ecosystem can thrive without Kodak, then it sounds like you don't expect Kodak to add any significant value and I may as well use any immutable public record, of which there are already countless legally tested options.
If you mean that if Kodak goes away then the rights contained in their ledger stick around as a historical document, then it explains why they need a public and immutable ledger (and a decent third-party archival service), but it still doesn't require trustless or decentralized.
A blockchain works, in the same sense that calling a ride sharing service to take me to the coffee shop half a block from my house works. But I can just walk half a block instead. As far as I can tell, the blockchain doesn't allow Kodak to do anything that they couldn't have done 20 years ago if they had wanted, and it's much more complicated (and therefore much more expensive and error prone) than many other data persistence layers.
To be clear, I don't have a dog in this fight. Tokens may be the Next Big Thing, I don't know. But it'd be really nice to have a full conversation on the topic that didn't either go off the rails or devolve into a political diatribe as soon as I ask a question about intrinsic value or zero sum games.
I guess you could chalk it up to a difference of aesthetic opinion. I don't want to think about buffers or readables. I want to think about loops and strings. Looping over a collection means `for range`, so I'm gonna assume that Just Works. Maybe `for range` is just syntactic sugar for `bufio.Scanner` under the hood, but I don't want to care while I'm using it.
I want to think of a file as a black box full of strings. What's actually in the box? Don't care. How do I get lines out of the box? `for _, str := range blackBox`, same way I loop over every collection. How does that actually work? Don't care. Whoever implemented the box has to care, of course, but I sure shouldn't. I've got more important things to worry about, like whatever it is I actually want the code to do. Every character that isn't about whatever it is I actually want the code to do is a problem.
Having primitives and builtins that only work sometimes (specifically, with a short list of builtin types and aliases for same) means I can't just use the builtins without thinking about what I'm using them on. Having to crush down to a lowest common denominator means that what's in my brain while I'm reading and writing code isn't strings and what I actually aim to do with them, it's how the Reader API works, and whether I read a full or a partial line, and whether I need to handle errors before or in or after the loop this time. I want to think about my problem domain, but Go keeps dragging me down into the weeds.
That doesn't justify why anyone else should be shoehorning blockchains into their projects.
Earlier today I saw that Kodak is going to be launching KODAKCoin later this month as a mechanism to somehow assist photographers in selling and distributing their work. Presumably Kodak trusts Kodak. Any photographer who wants to use Kodak's tools to control the distribution of their work has to trust Kodak. Kodak has an IT department. They don't need trustless or decentralized. What they need is a boring ol' SQL database.
Maybe cryptocurrencies are a good idea, maybe they're not. That's more of a political and economic question than a technical one. Either way, they clearly do work more or less as advertised. What I'm still waiting to see is someone who is not a libertarian bent on the destruction of the global financial system using the blockchain to successfully solve any other previously intractable problem.
Here's how to read a whole file then loop over the lines:
file, err := ioutil.ReadFile("data.txt")
// some error handling
for _, line := range strings.Split(file, "\n") {
fmt.Println(line)
}
Here's how to stream a file one line at a time: file, err := os.Open("data.txt")
// some error handling
defer file.Close()
scanner := bufio.NewScanner(file)
for scanner.Scan() {
fmt.Println(scanner.Text())
}
if err := scanner.Err(); err != nil {
// more error handling
}
Here's how I, at least, would like it to work: fileContents := file.Read("data.txt")
for _, line := range fileContents {
fmt.Println(line)
}
if fileContents.Err() {
// some error handling
}
fileContents := file.ReadStreaming("data.txt")
for _, line := range fileContents {
fmt.Println(line)
}
if fileContents.Err() {
// some error handling
}
The critical point is that I don't want to care whether `file` is a byte slice or a byte buffer, and Go doesn't let me not care. I want to be able to write code that deals with "enumerable data of some sort", once, and then works no matter how the caller decides to provide that data.Go (intentionally) makes it exceedingly difficult to obscure how a piece of code works from the rest of the codebase, and I personally think that's a fatally poor design decision. In my experience, it makes it difficult to decouple modules since code often has to be at least somewhat aware of quite a few implementation details of a library in order to use it correctly. It makes it really difficult to build higher level abstractions that don't leak. I have a much harder time in Go getting away from thinking in `int`s and `floats` and staying terms of the domain objects that I actually do care about.
"How" a piece of code functions is at best the third, and probably only the fourth most important question (behind "why", "what", and probably "when" if you use any concurrency at all), but Go forces it to be front and center at all times.
Incidentally, this is (as far as I understand) where most of the transaction fees ultimately end up. They're paid out to the miner who actually commits a transaction. Mining's a relatively competitive field so people aren't going to be able to charge much of a premium. The miners then have to turn around and use those fees to cover their costs, which in practice means their hardware costs and their electrical bills.
It's notable that the vast majority of the above are complaints by experienced developers working on large projects that need to be maintained and expanded for years. They're not the sort of thing you notice over a weekend of tinkering on something fun, and they're not the sort of issues that beginners will run into under any normal circumstances.
All of that adds up to a honeypot for newcomers. The language has some deep issues, but they're not the kind of things you're likely to notice until you already have 200k lines written and it's too late to switch to something with a steeper learning curve. Saving two weeks of confusion when you're learning ends up causing a lifetime of headaches down the road once you're an expert.
In other words, Go is PHP for systems programmers.
Person A sells their coin to Person B for $1,000. A is $1,000 richer and B is $1,000 poorer.
B sells the bitcoin to C for $2,000. A is still $1k richer, B is $1k richer, and C is $2k in the hole.
C sells to D for $3k. A, B, and C are all $1k richer, but D is out $3k.
At no point in the chain is any actual value created or destroyed; it merely changes hands. So even though the price keeps going up, the total value across all participants never goes up. The sum of the gains and losses of all participants is $0.
(Note that I'm using "$" to represent a generic indicator of value. Feel free to substitute € or ¥ or gold or shares of Facebook stock or whatever.)
===============
There are two simplifying assumptions above, both of which make Bitcoin not exactly zero sum.
Good news first. Bitcoin can and does create some value in the same way that other currencies do: by facilitating mutually beneficial exchanges of goods and services. Commercial use appears to only be a tiny fraction of all Bitcoin transactions (and an even smaller fraction that wouldn't have been facilitated anyway using some other means of exchange), but it does happen so credit where credit's due.
The bad news, though, is that all of the above requires electricity. A lot of electricity, as it turns out. Both the initial mining and every transaction thereafter require someone, somewhere to burn some amount of power in order to generate proof of work. Since proof of work is explicitly designed to be useless, all that spent power is essentially deadweight loss.
I haven't seen any good numbers on the first recently (and I would love to have my assumptions proven wrong), but given the ginormous estimates of electricity consumed by the second I have a hard time believing the network as a whole isn't substantially worse than zero sum.
> If I have no objective criteria, then it must be subjective, and then all that "simple" means is that "this is easiest for me right now"
Here's a few other (actionble) things that "simple" can mean.
* seems to reliably be easiest for me every time I look at it
* was judged to be better by the three or four people I could get to give me an opinion
* follows a heuristic that a bunch of smart people all seem to agree generally makes things better
* mirrors whatever we did on this project the last time we were in this situation
Even if all it means is "easiest for me right now", that's still probably going to get better results than "the first thing that popped into my head that might work".There is no objective definition of simple. On behalf of the maintenance programmers of the world, please don't take that to mean it's not worth trying anyway.
In a pure actor model raw channels wouldn't be directly available and I would be required to push to and read from a concrete goroutine.
"Which is the better painting, Van Gogh's Starry Night or a kindergartener's watercolor of their family?", on the other hand, appears to have a correct answer.
There are multiple competing definitions of "simple" with respect to code and multiple kinds of simplicity that often have to be traded off against one another, and reasonable programmers can and do disagree about which compromises to make and where. Code quality (including, but not limited to legibility) is in many regards a subjective endeavor.
That doesn't mean, though, that all decisions are equally justifiable. Trust your sense of aesthetics. It's usually trying to tell you something important, even if you don't know how to put it into words yet. With subjective endeavors there is no perfect, but there is usually better. Chase that.
This is easier to understand if you think about a specific traditional commodity, say timber futures. A timber future is created by some arborist who has some trees to sell, and will hopefully be ultimately purchased (after probably passing through a few investors' hands) by someone who has need of trees, like a sawmill operator.
But here's the magic bit: the same tree is worth more to the sawmill operator than it is to the arborist. Because she owns a sawmill, she can make finished boards from the tree which she can then sell at a profit. The arborist, who lacks a sawmill, can't take advantage of that opportunity. So there is some range of prices for a tree where the arborist and the sawmill operator will both think, correctly, that they benefited from the deal. By moving the same tree from someone who can't make further use of it to someone who can, the total value has gone up. And as long as the price of the future remains in that magic range, any number of middlemen can skim some off in between and everyone still wins.
Bitcoin doesn't work like that. There's nothing one can do with a bitcoin other than sell it, so there's no two parties who will mutually benefit from an exchange at any price. If two people disagree about the value they, personally, can extract from a fixed amount of BTC they can't both be right. They may disagree about their predictions or their risk appetite. But there's no sale of Bitcoins that both parties can look back on with perfect hindsight and agree that they both benefited.
Taxes are why I think a piece of paper with a bad portrait of George Washington has some intrinsic value to me, whether or not there's a secondary market for them. It's why I think the purchasing power of that piece of paper is anchored to a real phenomenon in the real world, and why I don't expect that purchasing power to move around much.
Think of it like this. If the dollar lost 20% of it's purchasing power overnight, I would be pretty damn sure something important has happened in American governance. Bitcoin just moved 20% because...?
According to https://bitcoinexchangerate.org/fees, getting a single transaction committed within the next hour costs just under $50.
I've heard plenty of ideas to make the Bitcoin network a little cheaper or a little faster. Occasionally both! I've yet to hear a good theory for how the Bitcoin network can ever get both 500x cheaper and 500x faster.
Let's say I think dollars are worthless, and my whole community works off something with real value, like shiny rocks. I'll still have to pay the IRS next April. They may take shiny rocks, but instead I could trade just one or two rocks for a big pile of worthless dollars and get Uncle Sam of my back for next to nothing. Unfortunately for me, every other shiny rock user in town is going to have the same idea, so they'll bid up the price of dollars until trading rocks for dollars doesn't feel any better than just paying my taxes in rocks directly.
The only faith that "full faith and credit" requires is faith that I'll have to keep paying taxes.