amarkov

The risk vector isn't that the dev team will push "PR 666: add master key to all wallets". It's that someone will introduce a subtle bug (such as a side channel leaking your private key), which goes undetected for months or years, until it's revealed that they've been slowly siphoning off and selling bitcoin they weren't entitled to. In a scenario like that, people might not attribute value to the current chain or the months-old clean one.

That's a great option for a founder to consider, but it means you won't have the resources to give compensation that's even competitive on paper.

Approximately every cryptocurrency buyer hopes for massive gains in the short to medium term. I don't think I've seen a single article saying "This ICO is going to generate consistent 9% returns, that's better than an index fund!"

Because of that, I don't think the possibility of the bubble popping can be built into the cost in the way you're implying. If you think there's a 20% chance your investment will dectuple and a 80% chance you'll be wiped out, you can split the difference to find your expected value. But since none of the market participants believe the current value is the long-term value, eventually it has to land one way or the other.

"Cap" doesn't mean what you're thinking in this context :)

Why is it worse to phone home and synchronize with a central authority than to phone home and synchronize with a blockchain?

No, there are explicit affirmative action laws too. For example, some federal contracts are set aside for what are known as "8(a) businesses": small businesses owned by disadvantaged groups.

All the projects I've most enjoyed working on had clear, explicit test failures, which almost always gave me enough information to hunt down what I'd broken and where. Obviously that's not realistic for some kinds of projects. But even in a legacy C project, if I had to pull out stack traces and profilers and GDB every single time I wanted to understand why a test failed, I would say I'm working in a pretty terrible codebase.

As you can see leaking through in a few of the examples, the scenarios where it matters are the ones where non-experts are reading to and writing from the database. If a data entry clerk is just typing values into a form thinly wrapping an INSERT, you'd better make sure any input that would break implicit assumptions is rejected. If you have a legion of Bobs from marketing who "know some SQL", you can't hand-optimize every single query they try to run.

When the database is just serving a webapp you control end to end, the only part that'll really have a huge impact is making sure you can partition by the primary key effectively. Which is good, because complex indexing schemes and foreign key constraints actually scale very badly.

A $700 lock isn't meant to be even an MVP. It's public proof that you're doing something, and a test that your production pipeline can generate reasonable quality products.

The strategic vision for these kinds of startups is that the industry is super far behind the times, and billions of dollars can be captured by just trying to innovate. Remember that Keurig was originally a $900 coffeepot.

I think you're underestimating just how many people believe the opposite. I wouldn't be surprised if something along the lines of "you know, it's great we have tech for our toys and Facebooks, but what really matters is making real stuff" is a majority opinion.

Does it, though? I don't think all the sledgehammer swingers starved to death when the jackhammer was invented.

When two banks transfer money, there's no concrete thing being moved or transmitted. It pretty much just involves bank B telling bank A "You hereby have $100k of my cash". So A needs some kind of global ledger to keep track of how much cash B actually has, and double check whether it's already told C, D, E that they have all of it.

There's no reason in principle a blockchain is better at solving this problem than a trusted central bank. But if the existing central bank is moving slowly or has annoying policies, it's much easier to bootstrap a blockchain than bootstrap a new trusted authority.

The relational structure maps cleanly to badly designed objects, where most classes have 5-10 fields and most fields are opaque data values with setters and getters. If you wrote classes like that in isolation, you'd have to do some serious work in code review, explaining why a hodgepodge collection of properties is a single unit of responsibility. But I've never worked in an ORM-using system where they weren't endemic.

But you can't just decide to avoid making assumptions, because the shape of your API strongly dictates the shape of your handler methods. I've never seen an API migration that didn't involve rewriting nearly the entire API layer.

Even worse, you have to maintain both the old and new versions of the API code, because turning off the old API endpoint is going to take at least a year.

The question is how much those architectures encode insights about how to play the game well, vs just how to play the game at all. After all, you have to teach general-purpose humans the rules of each specific game.

The legal system can't reliably provide for redress and restitution in the case of actual fraud, because the legal system can't pull money from thin air. In something like a classical Ponzi scheme, the fraudster simply does not have enough assets to give everyone back what they're owed.

It sounds like the basis for claiming this ICO has an investment component was that Munchee made marketing promises about how much money you'd stand to gain from participating.

Strict rules for tagging would just run into the same problems as strict rules for demonetization. LGBT groups won't be any happier to see their content publicly branded "sexually explicit" than just demonetized.

Well, shouldn't I? If the cost of a consistently growing S&P 500 is consistent inflation between 2-6% rather than wild positive and negative swings, that sounds like a win-win.

"Look at my great new financial product!" just isn't that interesting from a theoretical perspective, even if it really is cool and innovative. Knowing how to implement an immutable distributed ledger won't help you understand anything about the economy on its own.

But most non-libertarians believe in non-aggression and voluntary exchange too. They just argue that some taxes aren't aggression and some exchanges aren't really voluntary.

In Bitcoin, the number of outstanding currency units can be checked very easily.

What I care about as a consumer is being able to predict the value of my currency at future times. Bitcoin doesn't allow me to do this at all.

We can and do. The question is whether we need to go further, and tell everyone they can't let slur-users play with their stuff.

The standard example is Michael Clemens, who argues the total cost of closed borders to the world is in the trillions of dollars. If you want an article reviewing more views: https://www.washingtonpost.com/news/wonk/wp/2016/10/14/why-e...

The basic argument is just the standard free market argument. if A would like to sell their labor and B would like to buy it, and the government intervenes to stop them, that destroys whatever value they could have gotten from the exchange. The fact that there are some border markers between A and B doesn't change that value, although it may introduce externalities.

> How is it not assured that bitcoin will evolve? It evolves all the time. Are you even following the project?

I mean, are you even following the project? Very, very basic changes like "let's change this parameter from 1 to 2" are incredibly contentious, leading to hard forks and loud debates and furious accusations that people are shills trying to ruin Bitcoin for personal profit. If we can't even behave ourselves for a trivial proposal like Segwit2x, how could a truly significant protocol change ever get anywhere?

The argument is that Bitcoin is a decentralized, globally distributed Ponzi scheme, in the same way that it asserts itself to be a decentralized, globally distributed payment network. It seems unfair for Bitcoin proponents to go around saying "it's gotta be centralized or it's not really X".

Why does it matter that there's no single centralized group who does the marketing and controls scarcity? Bitcoin's entire selling point is that those kinds of things can happen without centralization!

> Obviously I can't verify this, but for example he had a professor who actively taught that nations are a completely artificial social construct, and as such all immigration policies of any sort are illegitimate and harmful.

But that's a very mainstream position in economics, with much stronger arguments behind it than ideological purity. And it's typically supported by libertarians more than progressives, since the arguments are weakened by strong government-provided social services.

This is what I worry about, when I hear people complain that their views aren't tolerated on campus. Are they really being shut down by intolerant professors who won't accept dissent? Or are they dismissing ideas they don't immediately find reasonable as far-left propaganda and refusing to listen?

But it's just as easy and just as safe to allow two schemas to co-exist within the same database. If you follow the necessary steps for a risk-free data migration, having both schemas coexist simultaneously and doing gradual switchovers, both models are going to be comparably difficult.

What schemaless lets you do is hide your risk better by disguising those steps. "db.table.update({$set: ...}, {multi: true})" looks friendly, but it's the same terrifying operation as running DROP TABLE A the instant you're done generating table B. And it looks easier, but that's because your code's beliefs about which schema it's reading from are hidden and implicit.

But most of the world doesn't trade in BTC, so most of the world could easily decide Bitcoin is worthless without a hit to their own pocketbooks.