Been using Hetzner Cloud for 18 months now, for various servers. Has proven incredibly reliable. Together with a very clear and straightforward management panel and unbeatable (AFAIK) performance/pricing, I haven't found a downside. A good alternative to their dedicated servers (which are also great) if you need more flexibility or less capacity.
I've been a happy customer of Netcup for many years now. If you don't need automation but just servers which you know you'll be running for years, they have a better price/performance ratio than Hetzner. But you should wait for their seasonal discounts, like easter, summer or the like, where they have really good offerings. Hetzner is more professional, though.
After many years of using Hetzner dedicated servers, I recently started using their US cloud for a project. So far, extremely happy, and it's very cost effective. Even cheaper than Digital Ocean (which I also use extensively).
This is almost cool, unfortunately the product itself (a network of bots to allow websites to be scraped when they obviously don't want to be) seems a little shifty. For example, put these three exhibits together:
Exhibit 1: The ScrapingBee terms and conditions state "We assume that you use the Website Platform and Services legally and ethically and that you have obtained permission, if necessary, to use it on the targeted websites and/or other data sources." This is even backed up with an indemnity clause in which the user has to cover ScrapingBee for any third-party legal claim arising out of their use of the product.
Exhibit 2: ScrapingBee explicitly advertises a feature allowing you to get Google search results via an API call. These results are presumably generated by scraping Google's search pages:
Exhibit 3: Google's own documentation explicitly states that automated querying is prohibited, so if you use this advertised ScrapingBee service, you are naturally violating Google's terms, and could be liable to cover ScrapingBee's legal costs if Google decide to come after them.
$1MM in ARR is all well and good, but there's a limit to how large this business can grow without being pursued by the websites whose scraping they are enabling, and in the case of Google, explicitly promoting.
Forbidding scrapping should be allowed and respected, especially scrapping by businesses.
Scraping by itself shouldn't be illegal per se but not respecting policies and using glorifed bot nets won't help anyone. Scraping costs the hosting person/ company money and/ or resources. For example, the advertised use case of scrapping a job board to create an aggregator for job postings is maybe good from the point of someone searching for a job but a hefty punch to the hosted of the job board that has potentially hefty costs (running the board, moderating, ...) without any gain.
Scrapbee is not helping anyone but themselves and is only challenging the legality of commercial botnetes IMO.
Edit: changed 'public botnet' to 'commercial botnet' in the last sentence
It's a tug of war between "acceptable behavior" and "bad behavior", but in the interest of an open internet, this cat and mouse needs to exist. Service providers negatively impacted by scraping can price in their mitigations.
You’ve got to really find your niche. I make around $1.5M profit per year from an independent website that takes an hour of two of work per week, me only. It’s been running for 15 years. The whole thing was a freaky case of perfect product and timing and there was definitely luck involved.
Am I the only one who thinks they want to push the market into applying strategies that they can then trade against? This is classic Wall Street, persuading the masses to take the wrong side of bets.
That was my first thought too. And even if that’s not what GS intends to do, it will still be the end result, because their non-public automated trading will quickly become adversarial to this.
I've been working on DLT / enterprise blockchain technologies since 2014 and have insight into hundreds of projects, a small number of which made it to live production. Here is the bottom line: yes, it's mostly hype, but this technology does have genuine use cases - when you want to build an interparty database-driven application, and cannot find a suitable place to put the database, because of business concerns or regulation. This is fairly niche, perhaps 1% of all interorganizational database applications, but there are certainly cases where it is the right solution. The majority of blockchain projects undertaken still do not make sense, but this is gradually getting better over time.
Can you let me know how these "private" blockchains utilize proof of X to determine consensus? E.g. proof of work, or proof of stake, or something else?
The thing I never understood with private blockchain tech is that the "traditional" blockchain (i.e. Bitcoin) relies on proof of work, and the only way this is viable is to have tons of resources working on these proofs so that you don't get a 51% attack (there have even been a bunch of articles about how smaller coins actually are very susceptible to a 51% attack by a decently funded attacker).
For a private blockchain, though, it never made sense to me as to who would serve the role of the miners with sufficient incentive to prevent a nefarious attacker. If on the other hand you are in a system where the participants agree as to how they will trust each other, well then you'd be back to a situation where the byzantine model isn't really necessary and you can just go back to a cryptographically signed ledger a la the Quantum Ledger DB that AWS just announced.
Would really appreciate someone explaining this one to me!
A useful term here is "Nakamoto consensus," which I think refers to the proof of X thing you're talking about -- consensus schemes that are resistant to sybil attacks among anonymous validators.
And I think you're right -- adding Nakamoto consensus to private blockchains makes no sense, because by definition they don't have arbitrary validators. And without Nakamoto consensus, "blockchain" is just rebranding of old and boring tech.
A distributed merkle-chain database is still pretty innovative. A good example is git. I think what many private groups want is a "binary git for transaction data". Everybody can review their own copy of the shared chain with signing of new links in the chain.
Now that isn't really a full blockchain, but is a different kind of thing from a central RDMS.
Except the issue is that Git, which includes validation and history integrity, was invented in 2005 and predates the publication of the bitcoin whitepaper by 3 years.
The point being that all the hype about "blockchain everywhere" came about because of bitcoin. If people are now starting to refer to just the "hash of blocks with previous blocks" (i.e. the "Timestamp Server" section of the original bitcoin whitepaper) as blockchain withOUT the proof of work/stake part, well then you really are just rebranding old tech as blockchain, because it was the proof of work part that was really the new thing in bitcoin.
Proof of work is required for distributed consensus; without that you need a centralized repository like GitHub or Linus to bless the current state of the database?
Well proof of work is used to get consensus and prevent double spend in cryptocurrency though there are other mechanisms being tried like proof of stake.
With Git for code you don't really need consensus - I can have my fork and you can have yours.
There are a variety of formal consensus algorithms uses for enterprise blockchains, but they are all some variant of voting schemes based on validator signatures. Nothing like proof-of-work is needed to ensure that one bad actor, or a small number of bad actors, cannot break the network's consensus. If you have just one validator, like QLDB, then you're back to a centralized scenario.
The problem is that having a non-BFT consensus is the same that using database nodes and if you use BFT consensus you don't have the performance required for most use cases. BFT-SMaRT supposely achieve 80k tps for a few nodes but when you scale to more nodes the performance degrades substantially.
Another issue against the DLT hype is that the blockchain does not provide security where 90% of the whole architecture is outside the blockchain, less if there are many few nodes.
There might be some constant factor penalty, but we can shard BFT systems much like we do with Paxos etc. See Shasper for example -- it won't have any practical limits on throughput.
Shasper[1] "Note: This is an experimental project. Everything will break, and it may disappear without any notice!" (sic).
Until we don't see a community working on adversarial attacks, we will not know if it is secure of not. There is concrete research about BFT since 1982.
Is your concern that the algorithms involved in schemes like Shasper might not be correct, or that their economic assumptions about attacks might fail?
I think it's very unlikely that any of the theoretical ideas behind Shasper are incorrect. Casper itself is simple and comes with a simple proof, and it's similar to an old algorithm by DLS [1], which also comes with a proof. Sharding does introduce some other machinery, like VDFs for randomness (specifically [2]), but that has been vetted by plenty of cryptographers such as Dan Boneh's group.
So even though there aren't any large-scale deployments of BFT algorithms yet, the approach is widely thought to be sound. I'm working on a blockchain based on sharded BFT, as is Ethereum, RapidChain, NEAR Protocol, and others.
It's always possible that our economic assumptions will fail, but they're not radically different from Bitcoin's. You can attack Bitcoin by buying 51% of all hash power, or you can attack a BFT system by buying 34% of all stake. Either way it comes down to making an assumption about the attacker's funding.
The 'corporate blockchain' described above would probably be a federated one. Participants would use private keys to sign and validate transactions, with full knowledge about who else is in the network. It's a simple quorum mechanism, or some elaboration thereof.
It is not 'trustless', but it is decentralized. You're basically relying on a majority of participants to behave ethically and not collude. In a situation where collusion is impractical or has little reward, this can function fine.
An example of this is Blockstream's 'Liquid' crypto which is validated by crypto exchanges. The security model of this coin isn't great compared to Bitcoin, but it arguably has advantages over the simple custodian model.
If the participants trust each other not to gang up on a minority but otherwise don't trust each other then BFT consensus is appropriate. As the OP said, that's around 1% of cases but maybe those cases are valuable.
> when you want to build an interparty database-driven application, and cannot find a suitable place to put the database, because of business concerns or regulation
If you're operating a legal business, a centralized database hosted by an industry mutual or regulator beats a blockchain.
Yes, that's true. But in some cases an industry mutual doesn't exist, and the regulator doesn't want to manage the database. Then what? It can be cheaper and easier to deploy a blockchain than to build the necessary organizational structure to run a central database. Like I said, it's niche but it happens.
> in some cases an industry mutual doesn't exist, and the regulator doesn't want to manage the database. Then what?
If you're at the scale where broad co-ordination is a problem, you're at the scale where the big boys can arrange a meeting. Alternatively, if you're at a scale where someone can get everyone on a blockchain, you're at the scale to create an industry organization.
I'm sorry but this does not always apply in the real world. Someone getting everyone onto a blockchain is a one-time project, perhaps with an annual maintenance fee. Running an industry organization is an order of magnitude (or two) more expensive. Trusting someone to build an (open source) application is not the same as trusting them to centrally host it.
How about a thing that's almost-but-not-quite a blockchain? E.g. a decentralized multi-master Event Sourcing datastore. No proof-of-work, no mining, no ledger. Anyone who can connect to the network (i.e. is whitelisted) can append whatever they like, and it'll get replicated to everybody. But nobody can delete/overwrite (without losing consensus); and every event is signed by its emitter. It's just an append-only log file that happens to exist in several (geographically distant) places at once.
Get the actors together to standardize a format for the messages everyone's emitting, and then make some software (one shared implementation, many different ones, doesn't matter) to parse the log stream into a point-in-time representation you can load into an analytics tool.
Seems to me that that sort of technology would fit this use-case a lot more closely than an Actual Blockchain™ would.
No. A log file under Paxos, for example, is not a blockchain.
A blockchain is a chain of blocks. A block is a persistent record of all the information required for the consensus process, which is held onto by a node after the consensus process has completed for that node. A new blockchain node bootstrap-syncs to the network by just receiving blocks at random from peers and then evaluating the consensus rules against those blocks in order to decide what its deduced copy of the "chain" shall look like. And you can never throw those blocks away (just keeping the transaction log), either, because a new peer might want to bootstrap itself from you.
This is not how multi-master sync in e.g. etcd or Postgres works. In those, consensus is a process that happens between all the nodes registered to a given cluster at any point in time. Each consensus-step happens between a known, fixed set of peers (fixed for the duration of that step, that is), consuming a fixed set of data that must be the same on all peers (the database before the update), and producing a new artifact (the updated database) that should be identical on all peers. After the consensus step completes, the inputs required to re-evaluate that particular consensus step are discarded by all peers. You can't go back and "watch history" happen again. You can only know what you've got right now.
But, luckily, since what you've got right now is an append-only file, you can just read it and see everything that's happened historically. It's just a logical history, though, not the history of the consensus process itself.
New nodes in such a system don't re-evaluate history to "reach consensus." They just pick a bootstrap peer to trust and slave themselves to it, synchronizing until they're an exact mirror of it. But—because all the nodes in the cluster keep their state in lockstep under consensus anyway—every node that is "in consensus" is as good as any other node that is "in consensus" for bootstrapping from. (And if you happen to bootstrap from a node that is lying about being "in consensus", then you'll quickly find that you can't obey the consensus protocol with the rest of the cluster using the data you bootstrapped.)
A blockchain is a very specific kind of distributed database architecture. Just having a distributed append-only database does not automatically make something a blockchain. You can have distributed append-only databases that aren't blockchains.
(Heck, there's an even more trivial case: a distributed append-only database owned by one party. How do you build that? Just deploy a master and some read-replicas, and tell the master to be append-only by policy! It should be pretty obvious, I hope, that that is not a blockchain.)
Nah, git retains its commit history, so it's actually closer to a blockchain approach than what I'm describing. Plus, with git, the syncs [with git-push and git-fetch] are async, such that a "cluster" of git-using nodes is never "in consensus" as a whole.
Picture instead, something more like a document synced in realtime using Operational Transformations (via SubEthaEdit, Etherpad, Google Docs, etc.), purely peer-to-peer (so specifically like SubEthaEdit) and without any peer expected to retain any history of the OT sync process itself (so you can't "wind back" the document like you can on Google Docs.) Except, now, also picture that if you try to broadcast any OT events other than an insert OT, the other nodes will just ignore those OT events, causing your document to fall out of sync with everyone else's. So the document itself can only ever grow, and nothing can be redacted or changed once it has been inserted.
So now you've got this single document that everyone can "write" to (but never change anything that's already been "written.") Now just make everyone always put their new writes at the end, so they're not breaking up anyone else's message. Now you've got a durable, distributed message bus.
(If you've ever used a wiki Talk page—or the old original C2 wiki where every page was a Talk page—the rule there for posting a new "chat message" to a page, is that you should append them onto the end of the existing "chat messages" of everyone else. If you put it anywhere else, another editor will revert your edit. This rule by itself is enough to allow for a functional chat system/forum with a complete logical "conversation" history! Same idea here—just that it's the database-node software that's automatically "reverting" bad edits. In all other senses, it's just a regular distributed file.)
Git is a DAG where each child of a hashed node is equally valid. For transactions and assets, what we need is a linked list (a chain) and therefore, some rule like "the longest chain is the TRUE chain".
Blockchains are also DAGs. This is the basis of the 51% attack. It is completely possible for a blockchains to fork. The consensus algorithm is how a particular branch is chosen as the winner. But the reason you need them is because blocks fire DAGs.
Every successful cryptocurrency has had protocol upgrades which require governance and I imagine private blockchains will be similar. You can't just let it run. So if you have an industry organization to perform ongoing governance of the blockchain then it is probably cheaper to have that organization run a database.
Can you please give a more specific example to illustrate the case?
From my perspective, blockchains are suitable for two things: People who want to misbehave(therefore they don't have legal recourse, independent of the morality of the extralegal actions) and people at war with each other that still need to have a relationship with each other.
It's kind of the perfect technology for a collapsed civilization or the revolutionaries and criminals in the current world order.
No, not really :) More like Iran and Israel when they want to resolve a difficult situation in Syria where fighting is not preferred by both of the parties but they don't have a trusted 3rd party to handle the orderly resolution.
I've only worked on a single blockchain application, but this was my experience too. I was actually pretty skeptical when I was told we'd be working on it and figured it was just a hype thing, but the use case involved a B2B process that was well-established and used a paid intermediary to correlate data across businesses. We were pretty happy with the result. I doubt we'll ever see a middleman-free decentralized utopia, but I agree that it's a technology with some genuine applications.
The source for the article's "Blockchain study finds 0.00% success rate" headline is "We documented 43 blockchain use-cases through internet searches ... we found no documentation or evidence of the results blockchain was purported to have achieved"[0]. That isn't a huge sample size, and "internet searches" may have skewed the results towards the more dubious projects spending large amounts on SEO.
But never-the-less I'd echo the interest in reading details of a successfully implemented use-case for public blockchain technology, beyond cryptocurrencies. Based on some of the comments here hinting that there might be some, and assuming they do indeed exist, I suspect that they are not solutions that could be achieved only with blockchain technology (like cryptocurrencies), or even solutions that are significantly better (in terms of cost, effort, time to market or some other metric) with blockchain technology, but simply solutions where blockchain has been made to work (i.e. other approaches could have been too and some of those may have been as good if not better).
Not really. A few years ago there was a lot of hype around NoSQL and everybody wanted to jump on it only to find out that in many cases NoSQL didn't make anything better.
Yes I guess developers never really took to MongoDB, Memcache, Redis and such.
Not to mention object stores like Amazon S3 which are also a kind of NoSQL database and are totally useless.
I've always seen it as the following equation: is the cost of distrusting the other parties in the transaction lower than the cost of running a decentralized ledger? if yes, you shouldn't use blockchain. this is obviously oversimplification but i think you get my point.
Yea sometimes I believe the word "enterprise blockchain" makes about as much since as a "dry rain". Basically saying that the problems that blockchain solves are usually not problems that enterprises run into often, or can't solve using some readily available alternative (e.g., SQL). Blockchain clearly satisfies a need. It's just that the great majority of enterprises clearly don't have that need.
The only successful applications of business blockchain I've seen is in businesses where nobody trusts the brokers. For example, the diamond business has to keep track of where the diamonds came from and nobody trusts the brokers to not lie, so blockchain works here.
Exactly - if the diamond mines are honest then you don't really need to trust the middlemen. You could also see how many diamonds a certain mine was claiming to produce, and if that number seemed disproportionate to the size of the mine, people might stop treating diamonds coming from that mine.
when you want to build an interparty database-driven application, and cannot find a suitable place to put the database, because of business concerns or regulation
Technology can't solve this problem.
If multiple entities need to coordinate inside a mutually used product don't trust each other, then the problem is structural and needs to be solved with interpersonal, regulatory or political action.
No need to be glib. The kinds of situations that are being discussed as the best for blockchain are literally the most intractable - hence why I said it was not a technology solution.
If you're in a situation where cryptocurrency is the best solution for currency, then you're probably in a lawless wasteland with abjectly destructive governance systems.
Seems like in that circumstance moving is the right answer.
I'm not being glib, I'm observing that the global system of passports and visa controls makes "moving" nearly impossible. I nearly pulled it off just over twenty years ago, but I failed, and now I'm permanently stuck back "home". Cryptocurrencies won't help, they're just another way to do capitalism.
Yep, i've been trying to explain this to people on here for quite a while now. This is correct. Blockchains allow data and co-operation to be domiciled nowhere, which allows competitive actors to agree and co-operate.
It also enables otherwise untrusted actors to make trustable claims, bypassing the gatekeepers that would otherwise have mediated those claims. One tangible example is ICOs bypassing not just regulators, but banks and the financial industry that would normally have had to underwrite them. Obviously this particular example has some serious kinks to work out, but the ability to bypass the corporate gatekeepers (not so much the regulators) has value, I think.
> This is fairly niche, perhaps 1% of all interorganizational database applications, but there are certainly cases where it is the right solution.
So I personally think DLT is going to be one of those multi-quadrillion dollar technologies that come around every few hundred years. The real benefit of DLT is that it enables new types of human relationships. So thinking about it in terms of what percentage of your existing databases should be replaced by it isn't going to give an especially impressive result, because by definition your existing databases are going to model your existing relationships.
Think about what percentage of the stuff in your house you would own without the invention of double entry accounting. Unless you happen to have some veggies from the farmer's market or a sweater one of your relatives knit you, the answer is probably 0.00%. It simply isn't possible to manufacture things like the iPhone without double entry accounting, because without double entry it would be impossible to form the sorts of human relationships needed to produce such a complex product. And if we asked someone to take a look at all the stuff in their house a couple hundred years from now, I'm guessing that a similar 0.00 percentage of the stuff they own will have not have been created as the result of DLT.
The fact is that once DLT becomes ubiquitous it will no longer be cost competitive to manufacture and distribute products using only the sorts of relationships and techniques enabled by double entry accounting. And if anyone even tries it's going to be like bringing a knife to a gunfight.
I mean a good example of the need for DLT is the fact that no one in the country can buy romaine lettuce right now. Does it really make any sense whatsoever that no one in the country can eat lettuce for the next couple months just because one farm got contaminated with E. coli?
You seem to be suggesting that a distributed ledger would have made it possible for regulators or buyers to track the specific source of the contamination and pull it out of the food system. DLTs are starting to be used for that level of tracking for diamonds, but key to that system is the ability to establish a "fingerprint" for each diamond that involves a laser-inscribed serial number on each diamond.
So to apply that, wouldn't we have to somehow register each individual head of lettuce with a tamperproof fingerprint? Just registering the bags the lettuce came in isn't good enough; the "farm" selling you their romaine might actually be selling you romaine from somewhere else that they've repackaged. (If that wasn't the case, we wouldn't be having this lettuce problem to start with.) And this is setting aside the possibility that lettuce might be leaved/shredded before packing and shipping, because now we have to put that tamperproof fingerprint on each and every leaf.
Oh, also there's the thing about all the leaves actually being in contact with one another as they're shipped, so by the time the consumer actually eats the leaf and gets sick, the best you could possibly do is say "we think it's from one of these packagers."
Maybe you're envisioning some other way entirely for Distributed Lettuce Technology* to solve this problem, I dunno. But I have trouble seeing it.
*I'm sorry, but cut me some slack, the joke is RIGHT THERE
> the "farm" selling you their romaine might actually be selling you romaine from somewhere else that they've repackaged.
Think about it from a game theory perspective. Under the status quo, each party in the supply chain maximizes their profit by lying about where their supplies came from. Whereas with DLT, each party maximizes their profit by being honest about where their supplies came from.
As an example, let's say you hijack you a truck and swap out expensive lettuce for cheap lettuce in a way that circumvents whatever tamper proofing technology has been applied. Stuff like this happens all the time currently, and is wildly profitable. (That's why if you go to a sushi restaurant and get a bunch of assorted sushi pieces or rolls, there is roughly a 0% chance that your meal will actually consist of what you ordered.)
With DLT though this is no longer profitable, because if you sell the cheap lettuce as expensive lettuce then you now have to sell the expensive lettuce as cheap lettuce, because each head or crate or whatever still needs to be traceable back to the source. This means that your total profit from the transaction is just whatever you would have made without cheating, plus your costs of hijacking the truck. So all in all, a substantial net loss.
Sure, so each party in the supply chain registers their private key with a PKI by going to the PKI's website (e.g. GoDaddy) and sticking their USB fob into their computer. The PKI associates the private key with an identity, and allows private keys to be voided and replaced if they get lost or whatever.
Then as each head of lettuce is picked, it goes into a crate that's securely sealed and then signed with the farmer's private key in a way that originates that crate of produce on the ledger. When the farmer sells their produce to the middleman that transaction is also recorded, and so on, all the way to the end consumer who buys the produce in a grocery store or in a restaurant. (And consumers would just use their phones or credit cards for this, rather than using any sort of external fob.)
Then when the first person gets sick they report their illness as per usual. Nothing happens at this stage, because there's no way to narrow down what made the person sick. By by the time the second person gets sick (with E. coli of the same genetic signature), now you can find the furthest place back in the supply chain where both people's purchases intercept. So you can now see if e.g. the contamination came from a single farm, and if so only recall lettuce from that farm rather than all romaine lettuce produced worldwide.
Because the database is open anyone can download a copy, and there is no risk of a single entity imposing a 30% Apple tax on each head of lettuce or whatever. And each person benefits from participating, because it's a pareto improvement in terms of their profitability. (Now their products only get recalled when they are at fault, rather than their products getting recalled when anyone is at fault.)
How about the types of products that can't be stored in a secure package from producer to consumer through the supply chain but need somehow be processed within the supply chain? You know, at least something like 99.9999% of the products...
I'm not sure secure sealing is done or necessary. If you get ecoli then just asking who the lettuce supplier was is probably enough. The government inspectors can then go check them.
Suppliers at every step of the chain enter data into a blockchain. Every organization runs a node. Therefore they can’t lie later and tamper with records when something goes wrong. Investigators can trace provenance easier. That’s it really. An append-only cryptographically secure database would do that same thing, but that’s just another name for a blockchain, which is a rebranding of a specific type of distributed database that has enhanced trust properties.
> Blockchain requires distribution for trustless implementation though, which is the duplicated expense
Trust scales with something like Metcalfe's Law. E.g. a consortium of ten independent banks is probably 99% less likely to steal my money than just Wells Fargo. The idea that we need millions of independent entities to get substantially better security than the status quo is just propaganda that gets spread by Bitcoin maximalists.
There is a cost of duplication, but at the level of duplication you actually need the cost isn't that much compared to the benefit.
No, but it isn’t about lying as a matter of business, that would easily be detected and caught in most cases, and a large amount of work to continually lie effectively. If you have employees and machines writing lots of data it’s infeasible to tamper with it in real-time.
The tampering comes after the fact when a legal issue arises. The immutable nature of the ledger makes it an improvement over the past by preventing later tampering.
So why not use a central database and allow all stakeholders to replicate and keep their own logs of edits. It would be far more efficient. It would lack a certain buzzword though.
A blockchain isn't optimal for anything. If it was there should be some evidence of it improving something in the real world, no? Something other than a cult of buzzwords and speculation.
What was probably the original blockchain was created for bitcoin and is good for that. Though the paper didn't coin the word blockchain, it described it "As later blocks are chained after it, the work to change the block
would include redoing all the blocks after it."
Then after bitcoin had gone up the marketing guys saw visions of billions in free money and started saying blockchain, blockchain!
It is optimal for situations where you don’t want to trust a central institution. An asset worth $70bil from zero in a decade (Bitcoin) should be considered a successful experiment even if it disappeared tomorrow. Pure computer science, math, and game theory created it, and it’s quite impressive.
We are far beyond anyone reading this thread other than us, and I am happy to continue discussing because I hope I can convince you that novel technology is being created to solve real problems. It isn't the panacea that fraudsters have been pushing, but I believe interesting solutions and companies will come of this.
If you look at Bitcoin and the Proof of Work mining algorithm that was created to solve its BFT problem, what you have is a globally dispersed group of participants driving the cost of SHA2 hashing to as close to zero as possible. Electricity combined with computers can be converted to Bitcoin, which has value because a group of people believe it has value. You are optimizing everyone to solve that problem, and people are responding naturally to economic incentives.
I believe other problems can be reduced to a Proof of Work distributed problem to drive the cost to zero. LivePeer ( https://livepeer.org/ ) is a recently launched protocol built on Ethereum to drive down the cost of transcoding live video. This is a computationally intensive process full of proprietary technology and patents that forces video streamers to become beholden to centralized third-parties such as YouTube, Twitch, etc. LivePeer solves this problem by incentivizing global participants to commit transcoding resources to an open network, ultimately driving the cost of this to zero. This will reduce censorship and costs.
Beyond computationally intensive work and protocols, I believe that smart contracts will open up a range on novel use cases. For starters, pure digital assets will become a way to fund development of videogames. Free to play games like League of Legends and Fortnite sell in-game assets, but these are not unique - they sell as many copies as people buy. While this works for big players as a business model, I believe new, novel games will come from making game assets provably unique.
These are just a few examples, but many very smart, non-crazy non-scammy people are working in this industry and creating new technologies. It's sad that the fraud has poisoned the conversation so much, especially on tech places like HN.
I know people from Ethereum Foundation personally and it only strengthens my negative view of the space. You can believe whatever you want, but I'm interested in results and actually useful products. Currently there are zero. There are many who share your religious beliefs though.
Nothing I stated is a "religious" belief unless you think that technology predictions such as cloud computing taking over corporate data centers or the internet disrupting mail-order catalogs are also religious beliefs. I stated that Bitcoin drove the cost of SHA2 hashing to near-zero and similar mechanisms can be used for other more-useful problems. It seems from your post history that you have a knee-jerk hatred of cryptocurrency and blockchain technologies and nothing anyone says will change it.
It's a nice idea in theory, but the problem is that only one side has actual control/ownership of the domain at any one time.
If the startup owner gets control, they can decide to stop paying, and the original domain owner has to sue for their money.
If the original domain owner keeps control, and the startup does well, they can be held to ransom by the domain owner threatening to redirect the domain.
Of course in theory all of this can be prevented through contracts, but the prospect of having to use the (international) court system to enforce one's rights is not an attractive one for either side. Startups often run out of money, and domainers like to spot an opportunity, so there's just too much risk.
As an aside, names aren't actually that important, so long as you can own your namespace. Flickr? Facebook? Craigslist? These are all pretty bad names, but it didn't seem to matter.
Does this mean there's a business opportunity here, than? A 3rd party, escrow-esque middleman who holds the domain so that neither party breaks the agreement?
I've seen the best results with Tribal Fusion and Casale Media. Unless you're in a high-premium field, don't expect more than $2 EPM for a 300x250 (or equivalent area) spot.
ValueClick Media and Burst Media are a couple of other top tier ad networks to look into. Google AdSense is obviously another option worth considering.
Depending on your niche and traffic though you may be better either directly selling to advertisers (serving/tracking ads through OpenX, Google DFP, or OIO Publisher is pretty straight forward).
Again depending on your niche you might find a vertical ad network - there are these for food, health, religion, music, sport and pretty much any other popular vertical you can think of. They tend to get better ads at better rates - but obviously have higher entry requirements.
2=x^x^x^x... cannot be solved, since x^x^x^x... will only converge to 0 (if x=0) or 1 (0<x<=1) or -1 (x=-1), ignoring complex numbers. So the original equation is false.
As a simple counter-example to your claim, the sequence:
x, x^x, x^x^x, x^x^x^x, ...
when x = sqrt(2) is strictly increasing and bounded above, and therefore converges. It's not hard to show that it's bounded above by 2, because x^x^2 > x^x^x, and x^x^2 = x^2 = 2. Repeat for any length sequence of exponentiation.
maybe you meant 4=x^x^x^x^x^x... cannot be solved because there exists no x that solves the equation y=x^x^x^x^x... for a maximum value of y which is a positive real solution of the equation y = x^y. Thus, x = y^(1/y). The limit defining the infinite tetration of x fails to converge for x > e^(1/e) because the maximum of y^(1/y) is e^(1/e). The maximum value is smaller than 4 and thus no solution exists.
I didn't make "FU money" from an exit, but rather from the ongoing success of a couple of online businesses, which have been earning me far more than I know how to spend. When this started happening, my initial reaction was to be perplexed, because I no longer had a financial motivation to get up in the morning and work. Money had been the most salient part of my motivation for as long as I could remember.
But I found that I still wanted to work, and it took me a while to understand why. It turns out there are lots of other good reasons to create useful things that people will pay for, like self expression, connecting to others, a sense of achievement, and a feeling of contributing to the world. The money was still nice but became secondary. Still, it allows me the luxury of working on interesting things that I think people will like, even if I doubt I'll ever make much money from them.
I found that the main challenge of being rich is finding a way to spend the money in a way which contributes to my happiness, rather than detracts from it. This is harder than it sounds. The most obvious way to spend money is to buy an oversized home. But this is a really bad idea. First of all you have to spend a lot of time maintaining that home. But most importantly it will likely alienate your (presumably not so rich) real old friends who are still working daily to pay off the mortgage. How will they feel about inviting you over to their condo when you live in a palace?
The solution I found to the "friend alienation" problem is to spend money on personal experiences rather than visible possessions. You can eat out at fancy restaurants, travel the world and enjoy the best shows without your friends knowing what you're up to, at least not in detail. It really helps if you have a spouse and/or children that you can do this with, since they can make these experiences all the more fun.
BTW this also neatly dovetails with recent research on happiness:
The one rich guy possession I'm allowing myself to buy is a second home in a foreign country that I like to visit often. This will (hopefully) make those visits less hassle and more enjoyable, and again, none of my close friends need to know.
And yes, I worry about losing the money a little, and have taken a self-propelled crash course in personal wealth management. But luckily I find the subject quite interesting anyway, and I don't let myself lose any sleep over a couple of percentage points in yield. In the long run, we all die anyway.
To summarize, getting "FU money" been a net benefit in my life, but it took a lot of careful thought and planning to ensure it worked out that way.
Finally if anyone out there who's suddenly landed FU money is feeling a little disorientated by their new situation, I highly recommend reading "Escape from Freedom" by Erich Fromm, which is a wonderful book about the psychological and existential challenges that freedom brings.
It seems sad to own a second home and not share it with your friends. The thing that makes me the happiest is hanging with my oldest and dearest friends. That often happens at one of our parents second homes (I don't have one), so maybe that really changes things.
Where did you end up living? I'm facing a similar situation regarding my living situation. I live in the heart of Boston, but most of my close friends do not, and this does have an alienating effect. I've contemplated moving up north to andover (a rural town -- opposite of boston) to position myself closer to friends/family, but would have to give up the city life. This is one of my current issues that I'm mulling over... thoughts?
The problem is that "their life" is so much a part of "youe life" (for the poster above you). Good relationships with other people are a huge part of what makes life better. I've always imagined that if I ever get FU money that it would allow me to live closer to people I have good realtionships with.
I have near life long friends who I still see regularly enough but several of us live in different states / countries now. I wasn't implying that they should alienate themselves from their friends but they shouldn't make drastic changes to their life just to accommodate them. ( I consider changing your lifestyle + moving to a new location a 'drastic' change ) One the best things having FU money allows for is the ability to 99.9% of the time decide to travel to X at 1pm on Tuesday and be on a plane to X by 4pm the same day.
