Hacker News new | comments | show | ask | jobs | submit login
Cryptocurrencies will create a fifth protocol layer (startupboy.com)
214 points by tikhon 1349 days ago | hide | past | web | favorite | 58 comments

Interesting read. I'm all for decentralized systems but one important consideration which will likely be different for each scenario: is whether distributed consensus in x (ie. traffic lights, water, power) is more valuable to the participants than a statistical machine-learning based approach. The latter is optimized towards some predefined metrics (minimizing total average wait times in traffic), whereas a cryptocurrency approach is distributed to the whims/needs of independent actors ("I want to cross the street now").

The benefits of distributed independent actors is clear in some areas such as economics, where the system is so massive and chaotic attempts to control it via machine or human intervention often fail. Even when they continually adapt their models over time, they will never be a full replacement for the consensus of a market.

While markets are efficient they famously at times have a habit of acting irrational and counter-productive to participants needs. This is where in the present times human intervention (occasionally) out-performs pure markets. In the future, most of us expect machine-optimized models to out-perform both markets and centralized systems.

That may be the differentiation in the long term for which is better, which can provide the best value? Human consensus -> human consensus via machines -> machine consensus. We'll likely keep moving farther to the right of that flow as machine learning (AI) becomes better.

>While markets are efficient they famously at times have a habit of acting irrational and counter-productive to participants needs. This is where in the present times human intervention (occasionally) out-performs pure markets.

I think that this happens because markets are not yet perfect. You end up with conditions where one party can gain by doing damage to the rest.

As time moves forward, I imagine that markets will get a lot better. Game theory is a growing field where people are exploring this problem. I think that in many ways, cryptocurrencies address this problem for certain applications, and will continue to improve as we figure out exactly where cryptocurrency is most useful to us.

Markets can not change the fact that humans are not rational, no matter what assumptions people like to make about that. Game theory is littered with examples where the rational behaviour is X, but where humans largely favour decision Y because X rubs us the wrong way in some way or other. E.g. humans are in some cases perfectly content to put our lives at risk out of sheer stubbornness if someone has annoyed us enough - accounting for that in systems aiming for perfection is at best incredibly hard, but far more likely pretty much impossible. You won't see perfect markets. There is no "yet".

I don't think this is about human rationality, or a lack thereof. It's a about whether individual rationality leads to group rationality. Whether the interest of the individual is also the interest of the group. This story is a good example: https://www.youtube.com/watch?v=sb5hr-f3Tfg#t=95

This sums up my original comment perfectly, thanks.

I think you are right that things will improve, but for exactly the wrong reason. Truly efficient markets are the toy problems of economic modeling, not typically achievable in real problem domains. Perhaps counter intuitively, I think we will gain efficiency by getting better at modeling the inefficiencies... but the end result of this is no more a "pure" (in your sense) market than a modern particle model consists of Aristotelian atoms.

Having the intended behavior as an emergent property of a lot of independent actors is always better than programming it top-down in a way that can be controlled by a single entity or shutdown.

Unless you're trying to make a specific thing happen quickly. Emergent properties are are very hard to construct intentionally and are often unexpected. It's easier to reason about single-threaded programs or about multiple threads acting independently. Once you're talking about multiple threads of execution that don't act independently systems can get pretty hairy. I think that's the reason client-server/master-slave architectures dominate computing today. Here's hoping for a p2p future!

Unless you want to go to the moon or something (pun intended).

Economically, adding such a layer creates perverse incentives. My router becomes profitable when I make its bandwidth scarce. The same incentive applies to everyone else with a router.

My ISP's gateway agreements become structured around a new definition of efficiency. Extract the maximum possible toll for each bit.

This new definition means, the more spam received The more my email host can raise the tariff. It can hold my incoming mail hostage.

The logic which underpins the idea is the finite pie. It ignores the possibility that network effects offset the cost of infrastructure even though that's what has driven the internet and mobile cell networks to vast scale over the past twenty years.

But it's still a great thought provoking article

In the world of ISPs, the potential pie is a lot bigger than our current pie. If you reduce the barrier to entry, a lot more people will find it worthwhile to spend money on being competitive.

If you make bandwidth scarce and expensive, I'll come in with my own router and charge less than you. Right now that would cost me millions of dollars. But if just needed $10k or $20k in capital to start profiting from my whole neighborhood, you might see a lot more ISPs cropping up.

I also think that decentralization will start to play a much bigger role in all of this. It's hard for you to hold my mail hostage when I'm using the decentralized MailCoin to manage my email.

Right now, cryptocurrencies aren't really strong enough to do all of this. But maybe in 5-10 years they will be enough to be the fundamental 5th layer mentioned in the article.

> My router becomes profitable when I make its bandwidth scarce. The same incentive applies to everyone else with a router.

If you make your bandwidth scarce (and expensive) someone else with a router may be incentivized to make their bandwidth slightly cheaper; so you end up with zero profit (as you have no customers). This is the fundamental reason why market-based strategies are effective; you are competing with everyone else's router, not cooperating.

In a finite pie model, yes, there's a Hobbesian war of all against all. Another model has Apple and Google agreeing not to poach each other's employees.

The idea of micro-transaction tariffs for traffic on the internet has been around since the 1990's when people were not sure that the internet could scale using the shared bandwidth model. It did, and micro-transaction tariffs never took off because it didn't solve an actual problem.

The article doesn't mention any existing problems that micro-currency tariffs would solve. The only problem crypto-currency in its current form solves is one of the minor problems with micro-transactions - it more easily allows for very small values to be treated as integral outside the system of micro-transaction - i.e. crypto-currency in its current form might not require aggregating many micro-transactions in order to purchase goods or services unrelated to the internet.

> My router becomes profitable when I make its bandwidth scarce. The same incentive applies to everyone else with a router.

This is a case where the public goods problem works in our favor.

Assume there are many routers, owned by different people, and lower total bandwidth increases total group profit.

If a person is providing 5% of total bandwidth and increases it to 10%, the total bandwidth only increases by about 5%, decreasing overall profits slightly. But that person's share of the profit doubles. Consequently everyone's selfish interest is to increase bandwidth.

Of course this only works out well if there's plenty of competition, rather than the local near-monopolies we mostly have now.

More likely the opposite will happen, as thousands or millions of people will become "ISPs", and rent their bandwidth. I think it will be more like the storage competition, where it gets cheaper and cheaper all the time per GB.

Most people's routers don't sit between me and what I am interested in - e.g. your router probably isn't between me and HN. Instead the routers between me and HN are run by big boys not enlightened individuals. Tor only works because their is no cost to linking the network.

The analogy, I would use is banks and there reconfiguration to maximize fees. They still make money from loans, but minimum balance fees and ATM surcharges carry much less risk.

This reminds me of a very tangible shortcoming in the OSI model that <https://en.wikipedia.org/wiki/Host_Identity_Protocol> is trying to address and which is, in my opinion, far more important that exchanging value.

It is the fact that we always talk of machine addresses, and never of machine identities (except through DNS, but DNS is also about giving human-readable identifiers, so it cannot be decentralized <https://en.wikipedia.org/wiki/Zooko%27s_triangle>).

However, now that everyone is using public-key crypto, we should understand that a machine can be referenced by a public key, and that it can prove ownership of it to anyone who asks. (This can also be used to encrypt traffic, but this is not what I am thinking of.)

Hence, why do we connect to IP addresses, rather than connecting to public key hashes? Granted, public key hashes are not routable, but there could be a service to provide the mapping from hashes to addresses -- not DNS, because it doesn't have to give human-readable names (so doesn't have to be centralized), and because there is little penalty for receiving a wrong answer (as long as you always check the identity of who you are talking to.

I think that, had asymetric crypto been in widespread use before the OSI model came about, this would have been the natural way to do things. Now the problem is unsatisfactorily solved both in DNS (which is not the right solution, as I already explained), and in an ad-hoc way with TLS, in SSH, etc.; but this is still too high in the hierarchy, machines should be addressed with public key fingerprints unless we are concerned about actual routing.

The OSI model accounts for that in layer 4.

However, the IP based protocols didn't implement that piece, but let the protocols (TCP/UDP etc.) just use the layer 3 addresses instead of having their own layer 4 addresses.

I'll try to find some references, but back when TCP was conceived, the idea was to have layer 4 addresses too, but this was dismissed for simplicity.

This is the issue with Bitcoin. It's essentially a p2p network, the virtual currency aspect is secondary to this. It will be a major breakthrough if it's proven to be immune to Sybil attacks.

> Hence, why do we connect to IP addresses, rather than connecting to public key hashes? Granted, public key hashes are not routable, but there could be a service to provide the mapping from hashes to addresses [...]

As I understand it, this is already an issue with the IP protocol. Here's a Google Tech Talk from 2007 discussing the issue with having both the unique ID and location identifier be a single thing (IP address): https://www.youtube.com/watch?v=QIGSMLrU4Xw and the solution: https://en.wikipedia.org/wiki/Locator/Identifier_Separation_...

There's a few different systems that implement connecting to public key hashes. Most recently, cjdns has had a fair bit of attention, and it's backwards-compatible with IPv6-supporting apps.

I think that's pretty much how the routing works in Tor for Hidden Services and in I2P for EepSites (except that it's mixed with onion routing (Tor) / tunnel routing (I2P) to provide anonymity).

What happens if the private key is compromised, and you have to switch to a new one? Does the identity of the machine then change too?

Yes, but with IP addresses your identity changes whenever your connection changes, which is much worse. When using fingerprints, instead, the machine identity stays the same (and conceivably you would just have to ping a decentralized repository of "fingerprints => IP" mappings).

And with this identity it is easier to track you.

Nothing prevents a machine from having multiple identities.

Or for an identity to "jump" from machine to machine at times.

Necessarily, I would imagine.

From the comments section the author writes:

"You are correct in that it’s technically another set of application layer protocols – I was just being provocative with the title..."

sigh... so it is not a "fifth column"

yes, the bitcoin protocol did provide some interesting things but is not nearly approaching the level of hype and spilled pixels lauding it

Ethereum is planning to build a whole turing complete platform for new coins and other kind of P2P apps and services.



I work in the area and have probably researched it more than most... and from quite some number of angles (social, technical, regulatory, etc.). My take is that an asset-neutral, settlement-system neutral transaction layer will certainly emerge.

This layer will provide (1) a suitably generic model of transaction state (2) hooks for cryptographic, reputation and logistics/provisioning systems (3) precise but extensible description of transactions including both traditional and digital goods and services

It will also facilitate a digital market for RFQs and quotes, and become as important to the JIT/decentralized manufacturing industry, spare parts supply business and the management of power on electrical grids as it will be to general purchasing.

Our children will find it inconceivable that archaic, limited, centralized, third party, centralized trust based platforms such as Alibaba, Amazon, eBay, SAP or Taobao and their rudimentary reputation systems ever existed.

I've put some thoughts and proposals online at http://ifex-project.org/ .. some of these are in live use already .. but very interested in any feedback.

A couple reposts or so are ok, if the article hasn't yet received a significant discussion. That's one reason the dupe detector is deliberately left porous: to give good stories multiple cracks at the bat.

(Please don't abuse this, though; accounts that repost too much lose their submission privileges.)

This is some refreshingly pleasant transparency as to the spirit of the rules. Thanks!

Clerical staff at your service. While I'm at it: please don't delete and then repost a story. That's an abuse of deletion and we penalize accounts that do much of it. Instead, use a different URL.

Would you mind writing these down somewhere? I've done that a few times and now I have no idea if my account is penalized.

What do you mean by "writing these down somewhere"?

I took a quick look at your account and it's fine.

Your "while I'm at it" comment contained one rather specific rule that can penalize accounts. I (and presumably the parent) would much prefer a centralized list of guidelines, rather than trying to remember tidbits of advice sprinkled throughout threads.

Striving to behave well is pretty much the best guideline, and if you incur some punishment unjustly or accidently, then contact the HN moderators.

HN is not a "whatever isn't explicitly prohibited is allowed" system. Instead it flows from general principles, and one of those principles appears to be that if you're caught abusing the system, there might be negative consequences because abusing the system is detrimental to its integrity and probably creates more work for somebody.

This is exactly right.

I disagree that the rules stem naturally from common courtesy.

- We have a system in place that prevents duplicates.

- Except we expect you to find holes in it and bypass it when necessary.

- Except you should never delete the original before posting a duplicate.

- More?

One would think the existence of a dupe detector implied a rule against duplicates, much like a low fence still implies private property.

An analogy to futbol:

Good referees make the calls that need to be made at this time, in this game, with these players. They have discretion. Compare that to basketball where all fouls must be called even when calling the foul clearly rewards the team committing the foul and gaining that reward was the explicit reason for fouling.

The reason futbol can be officiated differently from basketball is because futbol has Laws and basketball has rules. The futbol referee doesn't judge events solely by the book, but also by their effect on the Spirit of the Game.

The duplicate post heuristic exists to prevent problems and maintain the general enjoyment of HN. It's not there to encourage lawyering up and arguing a case, because that's nothing but a headache.

If this is seriously likely to affect you, act on the side of caution. Act as if the rules were explicit and restrictive and the punishments severe. In other words don't try to get away with something, and if you do, don't complain if something unpleasant results.

As Thomas Hobbes theorized, the sovereign's sole responsibility is to do whatever is necessary to keep the peace and we cede some of our autonomy for the sake of that peace. It ain't a democracy.

[BTW: user 'dang' is the HN moderator]

At least in futball, you know who the refs are (hi dang!), what the rules are, and you know whether you've been red-flagged. On HN, the mods are new, the rules are unknown, and the default behavior seems to be not to tell anyone when they've been penalized.

You seem to be talking about a complete list of rules. It's doubtful that we'll try to formalize HN in this manner. For one, I don't think it's possible; but if it were, I doubt it would work, and if it did, it would probably do more harm than good.

I get that that's frustrating to anyone who would prefer a precise spec, but don't forget that there is at least some compensation for the lack of an exhaustive rule book: you can get answers to questions by asking us. Please send questions to hn@ycombinator.com.

This sounds reasonable enough. But how will I know when to ask a question? It's not just hellbans; it's my understanding that there is no notification when one's account is penalized for some technicality (e.g. deleting a post before posting a dupe).

The same way in which you know when to ask a friend, "Hey, is it okay if I ...?"

I'm sure sp332 meant having a centralized place to understand the intricacies of HN mechanics.

We'll certainly add to the HN guidelines over time—and "please don't delete and repost" is the sort of thing we'll add. We probably won't try to make a complete list, though; I doubt that's even possible.

In the short run, we're trying to answer specific questions with more transparency. Baby steps!

I was wondering why it had the ?q=1 values added to a blog URL.

Good eye.

This is a very good summary of a future, but I don't think any sort of coin system will be particularly effective at mitigating either the spam nor DDoS problem for the wide variety of cases: if a botnet captures a computer, I expect it would equally capture whatever coin-wallet is being used for default mail transfer and network access.

It would, but switching the use case from a 'normal' pattern to a hijacked pattern may need an order of magnitude more traffic and as such, more coins. But coins (or mining resources) are a limited supply, so this means the DDoS or spam could only work if the botnet will keep the volume of illegitimate traffic equal the replaced 'legitimate' traffic. This may cause some alarms.

But ultimately, your argument is: if one system can be cracked, a more complex system could also be cracked.

Certainly not a new idea, this approach was discussed in the early 2000s but instead using pennies. I've always been a skeptic of this approach as anything that has value will inevitably be traded for money making it entirely possible for organized actors to create inequity in the system to their own ends.

If you need proof-of-work for value to not reject an interaction as automated / meaningless, just use a Hashcash header, which is where Bitcoin got started anyway.

The problem is that the cost of a hash is several orders of magnitude more expensive on a mobile phone, than when using a specialized chip. Money, however, costs the same to everyone.

I predict that if hashcash ever becomes widely used, people will start trading hashes for money. Ie. instead of wasting 30 seconds of battery power to create a hashcash header on your mobile phone, you'd pay 1 cent to a service that does it for it. And this is exactly what Bitcoin does already.

Note that this already exists in the form of Bitcloud [0].

I'm skeptical about putting it in every conversation. If every peer has to pay to work on the internet, it will make bigger peers more important (because they have more resources) and it will force everyone to mine (instead of having only a minority of people mining today)

[0] http://bitcloudproject.org/

I hate to bring it to you, but bitcloud doesn't exist and probably never will, for good reason. The gnunet is very similar to what bitcloud would like to be, and it already exists for something like 10 years. Bitcloud.. is just a fantasy at this point. And i2p also works similarly. In i2p you need to have shared some bandwidth in order to get higher speeds. And there is also Tor, which runs on altruism. Bitcloud is just trying to attach mining and coin like properties to something that doesn't need it. If you want to add incentivesed routing, why not fork one of these projects and add it in? Lastly, there is no idea yet from the bitcloud community on how to securely add and integrate incentivesed routing.

I didn't know I2P also had some incentive system attached, but it doesn't sound like it's going as far as what the post is describing. I was just mentioning bitcloud because that's what they propose to do, I haven't followed their actual progress (maybe because there is none ?)

Concerning Tor, as far as I understand the incentive part is only active to make sure your host has a good enough average uptime, right ?

Yeah, Brian Roemelle had talked about this on a podcast several months back.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact