If their claim were true, I'd expect to know that straight away from the landing page
Well, how do you propose the details be presented "straight away"? They require a good bit of explanation, and a bunch of text "straight away" would make your eyes glaze over.
Scroll down a bit and the information is introduced in manageable chunks. Then there's the paper that salient linked to. You just have to scroll a little bit, and if that's too much for you... well, again, feel free to offer suggestions. :)
2) Namecoin is hard to use, so something new, let's call it DNSNMC, will be needed to make it easy.
3) A DNSNMC server will decode data from the namecoin chain, and you can trust that it is telling the truth because you already trust that DNSNMC server.
A trusted proxy/offload for namecoin lookups isn't a crazy idea, but it doesn't add much to the system.
I'd suggest rewriting this paper and removing all the political justification for why one might want such a system. Everyone gets that, but not everyone wants a system like this for the same reasons anyway.
And since it's of interest to you anyway, I'd very much like to read some analysis from you on Dan Kaminsky's criticisms of Aaron's proposal. Does Namecoin square Zooko's Triangle?
First, let me answer your question, "Does Namecoin square Zooko's Triangle?"
Yes, I believe it does. Whether or not Namecoin works depends on whether or not Bitcoin works. They are the same exact technology (they're just used for different purposes).
From what I could tell of Dan Kaminsky's comments, I believe his arguments boil down to the well known 51% attack. Two things of note here:
2. The 51% attack is still a real threat. The Bitcoin community is on it:
Proof of blockchain fair sharing is a draft Bitcoin protocol change
proposal by Iain Stewart, with the goal of allowing the network to
continue to settle on a sensible consensus blockchain even when
subject to a considerably- greater-than-50% attack.
The protocol is under construction. The following description is a
"teaser", establishing its basic flavour and sketching how it exploits
an asymmetry in the goals of the honest (<50%) and malicious (>50%)
miners to avoid the usual reductio ad absurdum argument against any
protocol surviving a >50% attack.
Re: "I'd suggest rewriting this paper and removing all the political justification for why one might want such a system. Everyone gets that, but not everyone wants a system like this for the same reasons anyway."
Given the well popularized "debate" on this topic, I think it's quite clear that everyone does not get that.
it doesn't add much to the system.
It adds:
- The ability for JS apps to talk to and retrieve info from the blockchain without a browser extension (this wasn't possible before. It's a significant thing IMO).
- A new meta-domain (.nmc) and corresponding RESTful API for manipulating the blockchain
- DNSNMC may also support DNSCrypt (so that adds secure queries too).
- A gateway for browsers and other software to verify SSL certs without having to run a local namecoind client. (Which means you don't need to pay for them anymore!)
Probably other useful stuff I'm forgetting at the moment. Perhaps others might chime in. Oh, see also related topic: "Transitioning the web to Namecoin by addressing squatters" https://dot-bit.org/forum/viewtopic.php?f=5&t=1439
Thanks for taking the time to research and respond! So:
1) Dan's comments on Bitcoin in that BI article are a bit subtler than that. The very last section suggests (to me) that despite what value the BTC protocol has, it doesn't "square the triangle."
2) Dan is mainly talking about Sybil attacks in his 2011 post. The difference between a 51% attack and a Sybil attack is somewhat blurry, but here's my understanding:
A Sybil attack can't be prevented if an attacker controls >33% of the nodes. This is a mathematical truth of distributed systems (cf. Byzantine Generals), but Bitcoin's proof-of-work is often cited as the first practical system to demonstrate a workaround.
The >50% problem becomes the new lower bound for attackers, because with proof-of-work, you can't just fake 33% of the nodes. They have to be participating in the number crunching.
However, recent research blew this entirely out of the water, at least as far as Bitcoin goes[0]. They propose a change to the protocol that makes it a >25% percent problem, but currently it is a >0% problem. That is kind of a big deal. There are some good ideas in the "proof of stake" discussions, but none of the answers appear to lend support to the "triangle is squared" hypothesis.
Now then: I think you misunderstood my remark about the political aspects. I'm not saying anyone agrees on who/what/when/why/how of privacy issues. If the goal is to describe a system that is resilient to eavesdropping, you shouldn't distract from that system in the same paper with so much argument about why you want a system resilient to eavesdropping. Spill your ink to convince people if your system meets the requirements you lay out. Finally:
- "meta-domain" is a very strange term to use. It makes you sound ignorant of the realities of DNS, whether you are or not.
- My statement was that a proxy to namecoin doesn't add much to the system. The first and fourth of your bullet points might be paraphrased as "but it adds a proxy to namecoin!"
- What would be the purpose of adding DNSCrypt to DNSNMC? What do you mean by "secure queries" there? Anonymous queries? Validated responses? It's okay if you haven't finished specifying DNSNMC yet, but I wasn't asking for guesses about what you might do in the future.
Meanwhile, don't let counter arguments discourage you, but remember that the problem space is large. Failure to solve a gigantic problem may still be success when solving a normal sized problem.
> The very last section suggests (to me) that despite what value the BTC protocol has, it doesn't "square the triangle."
How so?
> However, recent research blew this entirely out of the water, at least as far as Bitcoin goes[0]. They propose a change to the protocol that makes it a >25% percent problem, but currently it is a >0% problem. That is kind of a big deal. There are some good ideas in the "proof of stake" discussions, but none of the answers appear to lend support to the "triangle is squared" hypothesis.
I was looking for that paper a while ago! Somehow my google-fu failed me and I got distracted by something else, and so, forgot about it for a while.
Thanks to you, I've had a chance to download the paper and read it.
Indeed, at first glance it might seem like they're pointing out a big hole in BTC, but I don't think this is the case, and neither do a lot of other folks over on the BTCtalk forum. [1]
There is one big flaw in their paper that the authors acknowledge (quite poorly IMO) in their followup blog post to the reactions that they received [2], and that is point #9, that they for some reason buried toward the bottom of the blog post:
Our paper does not address what happens when multiple pools employ the
selfish strategy. But if all pools were selfish, the blockchain would
not make forward progress for large periods of time, while selfish
groups hoard their blocks. Then, perhaps, depending on the profit-
taking strategy of the selfish miners and their relative sizes, it
would take erratic large steps forward. Such erratic behavior would
not bode well for the users who want to transact in the currency.
Indeed, what happens if more than one pool decides to follow this strategy? They must have been too trigger-happy to publish their paper to analyze the significance of that rather obvious question, which demands an answer.
I say that it demands an answer because the probability that exactly one pool would implement this strategy is, I think, close to zero.
For some strange reason, the authors (in their blog post) decided to jump to the other extreme and analyze the case where "all pools were selfish"! Well, that's a rather silly thing to do, because you don't go from 0% to 100% in one leap like that, so their analysis there, and related commentary, can simply be dismissed.
The interesting question remains: what happens when some pools start to implement this strategy?
I do not know for sure, but I suspect that the result will be a wash, so to speak, and most likely will end poorly for the cheaters (when they are caught). Their entire paper is based on the absurd claim that a single selfish pool will grow, like some sort of cancer, until it reaches 51% proportions (and then it's game over). While this is a possibility, at the moment it seems like an exceedingly remote one. In fact, the more cheating pools there are that use this strategy, the less likely their vision of a BTC doomsday becomes. Which group of bandits should one join, and is it worth the risk?
Speaking of risk, Stephen Gornick quickly pointed out a simple technique for detecting these cheaters: "
Wouldn't it be easy to tell if a block seems to be coming from a selfish pool (as each new block will appear to be laggng since it has no recently arrived transactions)? So if this lag can be detected then cannot an incentive to honest pools be offered?" [3]
> If the goal is to describe a system that is resilient to eavesdropping, you shouldn't distract from that system in the same paper with so much argument about why you want a system resilient to eavesdropping.
On this issue, I think we simply differ in opinion. I did not consider that section to be a distraction. Rather, I considered it to be an essential part of the paper, without which it would have been lacking. I think it would have been a disservice to the two projects (and to the paper itself) had I left the motivation section out. Only a tiny fraction of the intended audience of the paper is like you (already convinced of the need for an ubiquitous surveillance proof system of communication).
> "meta-domain" is a very strange term to use. It makes you sound ignorant of the realities of DNS, whether you are or not.
What term would you prefer then? It's a somewhat novel concept (so far as I know).
> My statement was that a proxy to namecoin doesn't add much to the system. The first and fourth of your bullet points might be paraphrased as "but it adds a proxy to namecoin!"
I agree on your last point, that the first and fourth bullets can be (somewhat inaccurately) summarized in that way, but I strongly disagree with the notion that it "doesn't add much to the system." It makes Namecoin usable. That's huge.
> What would be the purpose of adding DNSCrypt to DNSNMC? What do you mean by "secure queries" there? Anonymous queries? Validated responses? It's okay if you haven't finished specifying DNSNMC yet, but I wasn't asking for guesses about what you might do in the future.
Sorry, by "secure queries" I meant "encrypted queries". It protects against another form of surveillance.
Thank you very much for your wonderful, very astute comments!
I'm one of the two authors of the selfish mining paper. Let me chime in on the selfish mining aspect of this generally insightful comment:
>The interesting question remains: what happens when some pools start to implement this strategy?
>I do not know for sure, but I suspect that the result will be a wash, so to speak, and most likely will end poorly for the cheaters (when they are caught). Their entire paper is based on the absurd claim that a single selfish pool will grow, like some sort of cancer, until it reaches 51% proportions (and then it's game over). While this is a possibility, at the moment it seems like an exceedingly remote one. In fact, the more cheating pools there are that use this strategy, the less likely their vision of a BTC doomsday becomes. Which group of bandits should one join, and is it worth the risk?
The revenue dynamics of selfish mining (SM) are such that two SM pools working independently are better off joining forces. The excess revenue for SM is super-linear in pool size. So, with X% of the mining power working selfishly, you make (X(1+eps))%, with Y% mining selfishly, I make (Y(1+iota))%, but if we combine forces, we make (X+Y)*(1+delta)%, where delta>eps+iota. So we not only get our normal winnings, but we win an additional reward for joining forces. And since there is nothing at the protocol level to break up large mining pools, there is an incentive for SM pools to get large and grow until the 50% point.
We deliberately deferred a game-theoretic analysis of selfish mining to a future paper, because such analyses tend to be highly dependent on modeling assumptions. E.g. would an attacker view reaching the >50% point as a complete failure event when all coin value drops down to 0, or as a complete success event? The answers on how to model this apocalypse depend on too many assumptions about the attacker, his motivation, and what others can detect about his power. A thorough job of modeling the game-theoretic dynamics of Bitcoin (with selfish mining) would indeed make an exciting follow-on paper.
> if we combine forces, we make (X+Y)•(1+delta)%, where delta>eps+iota. So we not only get our normal winnings, but we win an additional reward for joining forces.
I'm not convinced that that matters. Let's say you're right and that your math is flawless (it's late, so I haven't verified it).
Using his method (or something similar) it would be rather obvious that something was fishy about the blocks this group was publishing. If it could be developed into a proof, then the entire selfish pool would be permabanned from the network, publicly tarred and feathered, etc. and there would be no problem.
Am I missing something? (If I am, don't jump too hard on me please, I'm about to head to sleep! :p)
The math seems to be correct and borne out by simulations, even independent simulations devised by people who did not believe that the selfish mining attack would work [1].
So Stephen's point is that there may be operational procedures that might allow one to detect selfish mining. This is great, as this is what we want is for Bitcoin to deploy in-protocol incentives to break up selfish miners. But there are two issues: (1) I'm not sure that his suggested tactic of judging by the latest timestamp would actually work well for established pools. I suspect that some pools are less eager to update their xaction sets, and therefore might lose to selfish miners, and (2) even if these operational measures worked perfectly, they would succeed in lowering gamma. But even with gamma at 0, selfish mining is still a win for groups of size 33% and above.
> (1) I'm not sure that his suggested tactic of judging by the latest timestamp would actually work well for established pools. I suspect that some pools are less eager to update their xaction sets, and therefore might lose to selfish miners
I don't see a reason as to why they would object, care to offer one? Plus, since you point out a threat that I think needs to be addressed (thanks btw!), this can be mandated in an updated protocol if the Bitcoin (or Namecoin) devs feel similarly.
> (2) even if these operational measures worked perfectly, they would succeed in lowering gamma. But even with gamma at 0, selfish mining is still a win for groups of size 33% and above.
Here I think you misunderstand. The implications of my comment were not simply that gamma is reduced to zero, but that the whole problem is thrown out the window because the entire pool would be banned from the network (blacklisted). Their selfish blocks would no longer be accepted by the network, and the implications could be even stronger than that (transactions, connections, etc. could also be rejected).
>The implications of my comment were not simply that gamma is reduced to zero, but that the whole problem is thrown out the window because the entire pool would be banned from the network (blacklisted).
Ah, but even if detection worked perfectly (and did have a false positive rate of 0), who precisely do you blacklist? The Bitcoin wallet? It's trivial to generate more. The IP address? Which precise IP address? Even if you could locate the IP address of the submitting node accurately, a pool has many, and it's possible to get more.
Definitely was not implying the wallet, but more along the lines of an IP. Your raise a good point though, that IP addresses might not carry sufficient weight/reliability.
I must focus on other things now, but I want to thank you for bringing this problem to the attention of the bitcoin community, even if they have chosen to ignore it and pretend that it's a non-issue.
I look forward to reading your followup paper (if and when you publish it). I hope you'll have a good solution in it.
(My brain is tempted to consider some using sort of stronger identity system than IP addresses [like Namecoin], but I really don't like that. That could potentially cause far more severe problems, especially if done incorrectly. And it seems like a hack.)
On #bitcoin-dev, the BTC developers consider this problem to be a non-issue because they think it is easily detected simply by the number of orphaned blocks.
No one on the IRC channel explained how this problem would be handled once it is detected. They refused to engage in such discussion, except to say that they wouldn't use Stephen's solution because it could introduce other problems. The current response has been an almost resounding, "We're going to stick our head in the sand and ignore it." (And then downvote you on HN for bringing it up and attempting to discuss it. :p)
Perhaps you're being down-voted because this thread has drifted off-topic.
Sorry, this subject matter has been discussed and debated at great length in a dozen places. No one has the time to hand-hold each and every person who learns about it and freaks out, especially if they come off as demanding and abrasive rather than inquisitive and helpful.
Saying that it is considered a non-issue would be a misrepresentation. It exists as part of a large collection of things which are potentially concerning but which are not currently problematic. Your proposed urgent deployment of "fixes" carries enormous risk and so it absolutely will not be done. So far as I've seen none of the proposed "fixes" are compromise free and many carry new, subtle, and difficult to analyze risks which may have far greater practical implications than the problem they claim to solve.
From a more practical perspective, action has been taken to improve network connectivity so that achieving alpha much greater than zero should be impossible in practice, and do the extent thats successful then there is only an issue with >33% consolidations— which are already problematic for other reasons (e.g. they can reverse six confirms with a 20% success rate).
Your specific concerns seemed to be mostly related to mining pools engaging in this activity without the consent of their hashers, this particular threat is eliminated completely by hashers that use GBT and submit blocks themselves— as you were pointed to.
In any case, in the future when you find yourself sending demands to volunteer developers asking them when they will solve your pet concern you should first ask yourself when _you_ plan on solving it.
Perhaps you're being down-voted because this thread has drifted off-topic.
It's a security issue related to bitcoin, which in turn is related to Namecoin, which in turn affects DNSNMC. Seems fairly on topic to me, but others are welcome to disagree (just explain why if you do).
No one has the time to hand-hold each and every person who learns about it and freaks out, especially if they come off as demanding and abrasive rather than inquisitive and helpful.
Sorry, I did not realize that I was coming off as demanding and abrasive. I can see how "demanding" might have been seen now, and I apologize for that. Abrasive though? I don't see that, I was just asking questions and for help understanding the BTC dev's thoughts on this.
Note that I also asked whether there was a document (perhaps on the bitcoin wiki) that had all the explanations on it already. The response was less than helpful.
Your proposed urgent deployment of "fixes" carries enormous risk and so it absolutely will not be done.
I think this was simply due to misunderstanding. It was never my intention that any one "fix" be adopted immediately. I was just looking for reassurance that something is being done about this, even if it's just the reassurance that the devs acknowledge the problem and are investigating methods of addressing it.
Your specific concerns seemed to be mostly related to mining pools engaging in this activity without the consent of their hashers, this particular threat is eliminated completely by hashers that use GBT and submit blocks themselves— as you were pointed to.
And as was pointed shortly out by gmaxwell, that doesn't matter for those who choose not to. If it's a certainty (or highly probable) that the network will adopt GBT, and that somehow implies that the problem is fixed, then that could have simply been explained. Instead, I was kicked from the channel and then my posts here were downvoted out of spite.
In any case, in the future when you find yourself sending demands to volunteer developers asking them when they will solve your pet concern you should first ask yourself when _you_ plan on solving it.
I'm sorry you perceived it as me "sending demands to volunteer developers". For any part of that that is true, I apologize. Like I said at the start of this reply, all I wanted to hear was that something is being done to address this problem, and if not, why not.
As for me solving it, I had pointed out a solution that I thought was helpful (Stephen's), but folks chose not to discuss that in any calm sort of way. I don't know why. Perhaps you may want to re-evaluate the way you (and others) reacted toward someone approaching the community with a concern and asking questions. I am not some type of thing for you to feel threatened by. My intentions were benevolent. I come in peace. ;)
Actually, let me qualify that comment, I should say that it effectively does. As Dan notes, BitTorrent, for example, is considered to be a decentralized protocol, but it does have some centralized components "for a reason".
IMO, in practice, this is inconsequential, because those centralized components aren't critical pieces, and they are fully "hot swappable". Any one of those bootstrap servers can go down, and they can be easily replaced. They don't really hold any valuable information themselves, they're just entry points into a distributed network.
I'm glad you brought that line in the 2011 piece up, because it caught my eye too. I am not sure it's clear whether Kaminsky was talking about peer introduction or content discovery, though.
Regardless, this gets down to the crux of the "squared triangle" issue. Getting introduced to the network isn't the only place where centralization helps, and it's probably not even an important one, as you say. A human that wants to get on the BitTorrent network just finds a client binary. There isn't a need at any point to type bit torrent dot com into a browser.
Arguably, the human-oriented / memorable leg of the triangle can't be solved globally. Here's some really good thinking on the subject: http://stpeter.im/journal/1035.html
Well, how do you propose the details be presented "straight away"? They require a good bit of explanation, and a bunch of text "straight away" would make your eyes glaze over.
Scroll down a bit and the information is introduced in manageable chunks. Then there's the paper that salient linked to. You just have to scroll a little bit, and if that's too much for you... well, again, feel free to offer suggestions. :)
http://okturtles.com/other/dnsnmc_okturtles_overview.pdf
Edit: re: "lazy kit web site", the site was made from scratch by Will Stanley (and I wrote some of the JS for it). I think he did a great job.