OkTurtles + DNSNMC: Surveillance-free communication on your favorite websites(okturtles.com)
okturtles.com
OkTurtles + DNSNMC: Surveillance-free communication on your favorite websites
http://okturtles.com/
13 comments
Website lacks a summary of what this does exactly and how, other than "add turtle buttons that do magic encryption voodoo" - or did I miss it somehow?
The white paper is down the page a little:
http://okturtles.com/other/dnsnmc_okturtles_overview.pdf
http://okturtles.com/other/dnsnmc_okturtles_overview.pdf
[deleted]
Did you miss the prominently linked to white (ie technical) paper?
I'm not a cryptographer, I'm a potential user. If I was up for reading white papers on this, I wouldn't be interested in having buttons shaped like turtles.
What I'm asking for is a summary of what this thing actually does from a semi-literate layman's perspective...
What I'm asking for is a summary of what this thing actually does from a semi-literate layman's perspective...
Oh, don't worry. I don't believe the white paper is at that level. It has typos, smilies, movie references, it's clearly a work in progress, it's very short, and it's written at a high level. Clever logo by the way. http://okturtles.com/other/dnsnmc_okturtles_overview.pdf
[deleted]
[deleted]
Just clicked the link. I just see the usual lazy kit web site, and no prominently linked white paper. No, I didn't scroll or click. I just looked at where I landed. Nothing. Just standard bland marketing stuff, pushing something that comes across as snake oil. It makes fantastic claims that given what we know about the NSA and its tentacles, are very hard to take seriously. If their claim were true, I'd expect to know that straight away from the landing page, and be blown over by the storm such protection would mean. If any one really made it 100% impossible for the likes of GCHQ and the NSA to spy, all hell would break loose.
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. :)
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.
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.
I read the paper, and stopped abruptly when you said you haven't specified anything yet because you want to work with the Namecoin community.
This is what I think you're saying:
1) Namecoin successfully squares Zooko's Triangle.
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?
This is what I think you're saying:
1) Namecoin successfully squares Zooko's Triangle.
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?
Excellent comment.
For reference, dvanduzer is most likely referring to this blog post and the exchange that took place in the comments: http://dankaminsky.com/2011/01/13/spelunk-tri/
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:
1. See Dan's 2013 post on businessinsider where he appears to be retracting his words: "I Tried Hacking Bitcoin And I Failed" http://www.businessinsider.com/dan-kaminsky-highlights-flaws...
2. The 51% attack is still a real threat. The Bitcoin community is on it:
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
For reference, dvanduzer is most likely referring to this blog post and the exchange that took place in the comments: http://dankaminsky.com/2011/01/13/spelunk-tri/
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:
1. See Dan's 2013 post on businessinsider where he appears to be retracting his words: "I Tried Hacking Bitcoin And I Failed" http://www.businessinsider.com/dan-kaminsky-highlights-flaws...
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.
[0] http://arxiv.org/abs/1311.0243
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.
[0] http://arxiv.org/abs/1311.0243
Again, excellent comments! :D
> 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:
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!
[1] https://bitcointalk.org/index.php?topic=324413.0
[2] http://hackingdistributed.com/2013/11/14/response-to-feedbac...
[3] https://bitcointalk.org/index.php?topic=324413.msg3478147#ms...
> 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.
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!
[1] https://bitcointalk.org/index.php?topic=324413.0
[2] http://hackingdistributed.com/2013/11/14/response-to-feedbac...
[3] https://bitcointalk.org/index.php?topic=324413.msg3478147#ms...
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.
>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.
Ah, thanks for that interesting analysis!
> 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).
If there is just one cancerous pool growing, then doesn't that make the job of policing the network even easier? Have a look at Stephen's post on btctalk: https://bitcointalk.org/index.php?topic=324413.msg3478147#ms...
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)
> 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).
If there is just one cancerous pool growing, then doesn't that make the job of policing the network even easier? Have a look at Stephen's post on btctalk: https://bitcointalk.org/index.php?topic=324413.msg3478147#ms...
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.
Hope this is useful.
[1] http://hackingdistributed.com/2013/11/17/selfish-mining-simu...
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.
Hope this is useful.
[1] http://hackingdistributed.com/2013/11/17/selfish-mining-simu...
> (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).
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).
Yes, I believe it does.
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.
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
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
I'd have loved if instead of reinventing the wheel, they added support for GPG keys in web-based inputs, and distributed GPG keys in DNSNMC. GPG is already widely deployed (among the crypto-sensible people, of course), it would be sad if we had to restart from scratch.
But this is still a step in the right direction.
But this is still a step in the right direction.
(author here): GPG support for the web can be easily done with @okTurtles, and was part of the plan from the start. It's very easy to do that compared to the rest of the goals of @okTurtles.
One thing about that though, is that GPG-based communication suffers from all the problems described in the OTR docs (and the overview paper on the site, see sections on plausible deniability and PFS). But if you want it, again, it's very simple to transparently support GPG on the web (once the rest of the foundation is implemented), and I can definitely see how people would find that useful for forums, reddit, HN, etc.
One thing about that though, is that GPG-based communication suffers from all the problems described in the OTR docs (and the overview paper on the site, see sections on plausible deniability and PFS). But if you want it, again, it's very simple to transparently support GPG on the web (once the rest of the foundation is implemented), and I can definitely see how people would find that useful for forums, reddit, HN, etc.
-----BEGIN PGP MESSAGE-----
Version: GnuPG v2.0.22 (GNU/Linux)
hQEMA/H221DfyGXJAQf+IDMe33H8hz1MgYfqxGta/FauUinOWtXqT+xskkGtt+es wRE1stgcJeKlzFDMHMS99Cvfw1qUis+CMVUnrBJw3yn1tdNo3FV+V0BgMIJwTPGS nkHxeXsxHXcsgcyRhB1PEO2arPaiek9xqxwUehnsDHI8T6oAJaUhteNHo72ybM4S Q1vSY8/Ni6t7Uk5zjpsHPq+Jhi7+QA9L1xaJuNBcm1lQxE2hWyrdXRB7N+HMnvJR LMgZndBjoKeui032cbIV8z/N7n2YT8Vtx0syVkDT0KppcW4EcQyAp6hbRPrgnUMu jDLLwT1xSgPwtH8NPo0iuusGmONa+stGGmjwHnhiLNJxAZWGQM36uE+FA9bXUVDl ikp29kE8qmCijPIHSDUny6SiNUjrEJeQEBq4TJpU7GDEsOQKx2tjchOZyWQFpKWK mBPnU6H9uAAByM+t+ejG5lxxlp/R9eKBs+YSf7QT7H2sLR/KIwyuXNJg+oHBtzKY weo= =bZbG -----END PGP MESSAGE-----
hQEMA/H221DfyGXJAQf+IDMe33H8hz1MgYfqxGta/FauUinOWtXqT+xskkGtt+es wRE1stgcJeKlzFDMHMS99Cvfw1qUis+CMVUnrBJw3yn1tdNo3FV+V0BgMIJwTPGS nkHxeXsxHXcsgcyRhB1PEO2arPaiek9xqxwUehnsDHI8T6oAJaUhteNHo72ybM4S Q1vSY8/Ni6t7Uk5zjpsHPq+Jhi7+QA9L1xaJuNBcm1lQxE2hWyrdXRB7N+HMnvJR LMgZndBjoKeui032cbIV8z/N7n2YT8Vtx0syVkDT0KppcW4EcQyAp6hbRPrgnUMu jDLLwT1xSgPwtH8NPo0iuusGmONa+stGGmjwHnhiLNJxAZWGQM36uE+FA9bXUVDl ikp29kE8qmCijPIHSDUny6SiNUjrEJeQEBq4TJpU7GDEsOQKx2tjchOZyWQFpKWK mBPnU6H9uAAByM+t+ejG5lxxlp/R9eKBs+YSf7QT7H2sLR/KIwyuXNJg+oHBtzKY weo= =bZbG -----END PGP MESSAGE-----
So how do we read it?
Edit: I know public key crypto... I meant: where's the key?
Edit: I know public key crypto... I meant: where's the key?
You need his public key to decrypt it.
So I can go find his public key on a keyserver and decrypt this message? Is that what you're asserting?
I think you mean private key. If it were public key it would not be secure at all :)
No. You need his public key. His private key should be known only by him. That said, he also needed the recipients public key to encrypt it.
Private keys are private. Public keys are public.
Edit: I realise this is unclear. He needs his private key and the public key of the recipient to encrypt the message. Then only the recipient can decrypt the message. To do this, the recipient needs his private key and the encryptor's public key. Hope that helps.
Private keys are private. Public keys are public.
Edit: I realise this is unclear. He needs his private key and the public key of the recipient to encrypt the message. Then only the recipient can decrypt the message. To do this, the recipient needs his private key and the encryptor's public key. Hope that helps.
>Edit: I realise this is unclear. He needs his private key and the public key of the recipient to encrypt the message. Then only the recipient can decrypt the message. To do this, the recipient needs his private key and the encryptor's public key. Hope that helps.
Incorrect. To encrypt a message, you only need the intended recipient's public key. You don't need your own private key.
Likewise, for the recipient to decrypt, they only need their private key. No need for the encryptor's public key.
You can send messages to other PGP users without ever creating your own keypair. It's only to receive encrypted messages that you need a keypair.
Now, if you want to sign a message that you're sending, you need a keypair.
Incorrect. To encrypt a message, you only need the intended recipient's public key. You don't need your own private key.
Likewise, for the recipient to decrypt, they only need their private key. No need for the encryptor's public key.
You can send messages to other PGP users without ever creating your own keypair. It's only to receive encrypted messages that you need a keypair.
Now, if you want to sign a message that you're sending, you need a keypair.
> Incorrect. To encrypt a message, you only need the intended recipient's public key. You don't need your own private key.
I don't think this is right. The diagram here appears to depict otherwise: https://en.wikipedia.org/wiki/File:Public_key_shared_secret....
I don't think this is right. The diagram here appears to depict otherwise: https://en.wikipedia.org/wiki/File:Public_key_shared_secret....
No. This diagram is depicting the creation of a shared secret for symmetric communication. PGP is asymmetric.
I tell you what. Do you have a PGP keypair? Post your public key here (the one you would host on a public keyserver) and I'll show you a short script that can encrypt information that only you can read using your private key. It will use no other keypair besides your own public key.
I tell you what. Do you have a PGP keypair? Post your public key here (the one you would host on a public keyserver) and I'll show you a short script that can encrypt information that only you can read using your private key. It will use no other keypair besides your own public key.
You seem to be using encrypt/decrypt interchangeably. You had said:
> You need his public key to "decrypt" it.
My correction assumed that you had made a typo when you said "decrypt".
Also you only need the recipients public key to encrypt the message. [0]
[0] http://www.pgpi.org/doc/pgpintro/
> You need his public key to "decrypt" it.
My correction assumed that you had made a typo when you said "decrypt".
Also you only need the recipients public key to encrypt the message. [0]
[0] http://www.pgpi.org/doc/pgpintro/
The rule: A message encrypted with a private key can only be decrypted using the corresponding public key. A message encrypted with a public key can only be decrypted using the corresponding private key.
If the poster wanted all of us to be able to read it, they would have encrypted it with their private key. Then we'd just need their public key, which is published on keyservers, to decrypt it.
Why would anyone do this? Because it is a way to verify that the message came from a specific person or group. If you can decrypt a message with a given public key, you know "Only the people who have access to the corresponding private key could have published this message." You don't necessarily know who, in specific published it, but you can do things like determining that a batch of messages all came from the same group.
Now, if the person had encrypted it with a specific person's public key, then only that specific person would be able to decrypt it, because messages encrypted with a public key can only be decrypted with the corresponding private key. Being able to post private messages in public fora without needing to meet the recipient beforehand is one of the main features of public-key cryptography.
If the poster wanted all of us to be able to read it, they would have encrypted it with their private key. Then we'd just need their public key, which is published on keyservers, to decrypt it.
Why would anyone do this? Because it is a way to verify that the message came from a specific person or group. If you can decrypt a message with a given public key, you know "Only the people who have access to the corresponding private key could have published this message." You don't necessarily know who, in specific published it, but you can do things like determining that a batch of messages all came from the same group.
Now, if the person had encrypted it with a specific person's public key, then only that specific person would be able to decrypt it, because messages encrypted with a public key can only be decrypted with the corresponding private key. Being able to post private messages in public fora without needing to meet the recipient beforehand is one of the main features of public-key cryptography.
> If the poster wanted all of us to be able to read it, they would have encrypted it with their private key. Then we'd just need their public key, which is published on keyservers, to decrypt it.
That's really interesting, I had no idea that public key encryption could be used this way.
That's really interesting, I had no idea that public key encryption could be used this way.
I am not sure whether this is literally possible or not, but it doesn't make a lot of sense. Sending an encrypted message with the decryption key right along side or otherwise in public view?
The common use case is to _sign_ with a private key and _verify_ with the public key. If you need the contents of the message to be secret, you can use other methods. The signature proves something about the authorship of the original message.
For example, if someone wished to make a prediction about the future, they might write down the prediction, sign it with a private key, but then only publish the signature. Later, when the prediction turns out to be true (or false), they publish the original text. The public key can then verify that the precise text of the original prediction created the previously published signature.
edit: in this case, zobzu might have created a one-use private key, encrypted a prediction about DNSNMC with the corresponding public key, and will later publish that private key. Or it might be the output of /dev/urandom
The common use case is to _sign_ with a private key and _verify_ with the public key. If you need the contents of the message to be secret, you can use other methods. The signature proves something about the authorship of the original message.
For example, if someone wished to make a prediction about the future, they might write down the prediction, sign it with a private key, but then only publish the signature. Later, when the prediction turns out to be true (or false), they publish the original text. The public key can then verify that the precise text of the original prediction created the previously published signature.
edit: in this case, zobzu might have created a one-use private key, encrypted a prediction about DNSNMC with the corresponding public key, and will later publish that private key. Or it might be the output of /dev/urandom
That's how signing works. The signer generates a hash of the content being signed, and then encrypts that hash with their own private key. Then anyone with the public key can decrypt the hash, and then compare the decrypted hash against the hash of the content that they generate themselves.
Author here: yes, support for GPG is one way of using @okTurtles (e.g. with OTR off).
Your comment would be instantly readable to whoever the intended recipient(s) are, with no manual intervention on their part. (see also reply 'rakoo': https://news.ycombinator.com/item?id=6963081)
Your comment would be instantly readable to whoever the intended recipient(s) are, with no manual intervention on their part. (see also reply 'rakoo': https://news.ycombinator.com/item?id=6963081)
What type of OTR improvements suggested by Trevor Perrin did you use. The same ones TextSecure will be using?
https://whispersystems.org/blog/advanced-ratcheting/
https://whispersystems.org/blog/advanced-ratcheting/
We're actively following the work of Trevor, Moxie, and all the great folks at Open WhisperSystems. Some of their work is cited and analyzed in the paper that's on the site. Of course I'd love to use and keep up with the best ideas, whatever they happen to be, and so one of the design goals of okTurtles is to be somewhat protocol-agnostic, so that it's easy to incorporate better ideas as they come along, while maintaining backwards compatibility. At the moment, TextSecure's example of async-OTR, with their modifications to make the protocol simpler (3 DHE, and the ratcheting you cite), seem quite appealing, and unless we find something better, we'll probably use that (with the exception that we won't be relying on a single centralized server).
I'd be interested to see another comparison with DNSCurve on your page (http://okturtles.com/#DNSNMC):
http://dnscurve.org/
http://www.youtube.com/watch?v=K8EGA834Nok
It seems Aaron Swartz has inspired so many great projects. It makes me sad that he's no longer with us from such a young age. It seems he had a lot of potential to change things for the better.
http://dnscurve.org/
http://www.youtube.com/watch?v=K8EGA834Nok
It seems Aaron Swartz has inspired so many great projects. It makes me sad that he's no longer with us from such a young age. It seems he had a lot of potential to change things for the better.
It's tragic that Aaron won't be around to see (and aid) the coming wave of distributed direct democracy.
I'm really happy to see this here; I've tried to build a tool based on the very similar concept - initially just as a chrome plugin (I do see the irony), but ran out of time, enthusiasm. http://kaniowski.info/umshade/
Good luck, really want to see this getting popular
I like seeing people offering solutions against mass surveillance.
What I want to suggest is that you drop the requests you send to 3rd party services like Google. If somebody makes money off of collecting as much data about us as they can, it's Google, Facebook, etc. So, letting them track your users is a contradiction.
What I want to suggest is that you drop the requests you send to 3rd party services like Google. If somebody makes money off of collecting as much data about us as they can, it's Google, Facebook, etc. So, letting them track your users is a contradiction.
What I want to suggest is that you drop the requests you send to 3rd party services like Google. If somebody makes money off of collecting as much data about us as they can, it's Google, Facebook, etc. So, letting them track your users is a contradiction.
What are you referring to? There's no Google tracking code on the site. The only analytics is Mint (which is local to the server).
What are you referring to? There's no Google tracking code on the site. The only analytics is Mint (which is local to the server).
imho bitcoins technology is amazing and and the near future we will see a lot of new products, such as this one, that are built on bitcoin technology but aren't related to bitcoins.
You know, at the moment for me it feels as if this is exciting as if its on the cusp of something great but I'm not sure what it is or how to put it into words. Could you explain why it's amazing?
I too have this feeling, and made a post about possibilities for traditional state functions in the blockchain: http://www.wallstreetcrypto.com/2013/12/distributed-anonymou...
It's a very fuzzy concept for now, but I'm sure someone will come along and articulate it better.
It's a very fuzzy concept for now, but I'm sure someone will come along and articulate it better.
If its something that will work inside gmail/facebook frontends (web ui), isn't it inherently at the mercy of google and facebook?
[deleted]
See section "6.3 Note on JavaScript Cryptography" in the paper: http://okturtles.com/other/dnsnmc_okturtles_overview.pdf
I'd LOVE for something like this to take off.
From the whitepaper http://okturtles.com/other/dnsnmc_okturtles_overview.pdf
"The magic doesn’t stop there. DNSNMC isn’t just DNS + NMC, it’s also an HTTP server. DNSNMC provides its clients with secure access to the Namecoin blockchain itself through a RESTful API."
They're planning on shipping this browser extension with a hardcoded list of DNSNMC server IP addresses. Isn't that a central point of failure? (E.g. If an adversary mounts a DDoS against all servers in that list.) Adversaries wouldn't need to render the service unreachable, just slow it down to painfully-slow speeds for average users. Regular DNS is resilient to this because of its hierarchical design, but the paper seems to be proposing a flat list of DNSNMC servers that will be shipped with the extension by default. Since almost all users will stick with the defaults, subverting those servers would disrupt DNSNMC for most users.
Also, it's unclear to me how users or website owners use DNSNMC's REST API to update their blockchain identity entry. Is it password-based? Like, when a user first creates a blockchain entry, do they set a password they must remember? If so, then what happens when they inevitably forget their password or someone steals it via a key logger? It needs to be changeable in case the old password is compromised, but that causes a whole bunch of problem scenarios, like an attacker steals a password then changes it, then modifies the user's blockchain entry. How does a user recover his stolen blockchain identity?
Overall the whitepaper is a comprehensive survey of the current public key infrastructure landscape and embodies some interesting ideas for the future. While there are some very dubious ideas (like tackling all problems with JavaScript crypto) I'm cautiously optimistic about the overall direction this whitepaper is proposing, because something similar to this is a necessity: a distributed DNS system that doesn't rely on certificate authorities, and lets users distribute their public keys in a public way that can't be easily MITM'd. There are unsolved problems, like how users can recover a stolen identity, but this whitepaper takes care to be extremely clear that it's a work in progress, and that it's being made available to get early feedback on the design / to solicit ideas from the community. They don't pretend that they've thought of everything, which is nice.
They're working on an important problem (a future in which CAs are unnecessary + giving everyone a way to distribute encryption keys tied to your public identity) so this kind of research is sorely needed, and I look forward to seeing what their next step is.
"The magic doesn’t stop there. DNSNMC isn’t just DNS + NMC, it’s also an HTTP server. DNSNMC provides its clients with secure access to the Namecoin blockchain itself through a RESTful API."
They're planning on shipping this browser extension with a hardcoded list of DNSNMC server IP addresses. Isn't that a central point of failure? (E.g. If an adversary mounts a DDoS against all servers in that list.) Adversaries wouldn't need to render the service unreachable, just slow it down to painfully-slow speeds for average users. Regular DNS is resilient to this because of its hierarchical design, but the paper seems to be proposing a flat list of DNSNMC servers that will be shipped with the extension by default. Since almost all users will stick with the defaults, subverting those servers would disrupt DNSNMC for most users.
Also, it's unclear to me how users or website owners use DNSNMC's REST API to update their blockchain identity entry. Is it password-based? Like, when a user first creates a blockchain entry, do they set a password they must remember? If so, then what happens when they inevitably forget their password or someone steals it via a key logger? It needs to be changeable in case the old password is compromised, but that causes a whole bunch of problem scenarios, like an attacker steals a password then changes it, then modifies the user's blockchain entry. How does a user recover his stolen blockchain identity?
Overall the whitepaper is a comprehensive survey of the current public key infrastructure landscape and embodies some interesting ideas for the future. While there are some very dubious ideas (like tackling all problems with JavaScript crypto) I'm cautiously optimistic about the overall direction this whitepaper is proposing, because something similar to this is a necessity: a distributed DNS system that doesn't rely on certificate authorities, and lets users distribute their public keys in a public way that can't be easily MITM'd. There are unsolved problems, like how users can recover a stolen identity, but this whitepaper takes care to be extremely clear that it's a work in progress, and that it's being made available to get early feedback on the design / to solicit ideas from the community. They don't pretend that they've thought of everything, which is nice.
They're working on an important problem (a future in which CAs are unnecessary + giving everyone a way to distribute encryption keys tied to your public identity) so this kind of research is sorely needed, and I look forward to seeing what their next step is.
They're planning on shipping this browser extension with a hardcoded list of DNSNMC server IP addresses. Isn't that a central point of failure? (E.g. If an adversary mounts a DDoS against all servers in that list.) Adversaries wouldn't need to render the service unreachable, just slow it down to painfully-slow speeds for average users. Regular DNS is resilient to this because of its hierarchical design, but the paper seems to be proposing a flat list of DNSNMC servers that will be shipped with the extension by default. Since almost all users will stick with the defaults, subverting those servers would disrupt DNSNMC for most users.
This is a good point. Two things: (1) you stopped a bit short in your quote. Here's a bit more from the paper on that:
"To avoid falling into the same trap that web browsers enjoy today with Certificate Authorities, okTurtles will encourage the user to use their own DNSNMC server, whether it’s one that they have setup themselves, or one that belongs to someone they trust. Defaults are provided to encourage adoption and to make the software function immediately upon install."
(2) That paper is the first public introduction of DNSNMC, and I expect (and really appreciate) everyone who reviews (and has reviewed) it, and pointed out issues like this.
That said, this problem could be solved by something like a DHT [1]. Or, it might be a non-issue and not really need something that complicated. Just a live-updating list of trustworthy IP/fingerprint pairs (with bootstrap servers, protected by something like cloudflare), might be all that is necessary for the defaults (which again, the extension would encourage switching off of).
Also, it's unclear to me how users or website owners use DNSNMC's REST API to update their blockchain identity entry.
Yes, that API is being worked on right now, so your comments are definitely helpful, and you're also very much welcome to provide any and all other feedback. Here's another great place to do it: http://dot-bit.org/forum/viewtopic.php?f=5&t=1423
Thanks again for your fantastic feedback! (What a wonderful Xmas present! :)
[1] https://github.com/feross/webtorrent
This is a good point. Two things: (1) you stopped a bit short in your quote. Here's a bit more from the paper on that:
"To avoid falling into the same trap that web browsers enjoy today with Certificate Authorities, okTurtles will encourage the user to use their own DNSNMC server, whether it’s one that they have setup themselves, or one that belongs to someone they trust. Defaults are provided to encourage adoption and to make the software function immediately upon install."
(2) That paper is the first public introduction of DNSNMC, and I expect (and really appreciate) everyone who reviews (and has reviewed) it, and pointed out issues like this.
That said, this problem could be solved by something like a DHT [1]. Or, it might be a non-issue and not really need something that complicated. Just a live-updating list of trustworthy IP/fingerprint pairs (with bootstrap servers, protected by something like cloudflare), might be all that is necessary for the defaults (which again, the extension would encourage switching off of).
Also, it's unclear to me how users or website owners use DNSNMC's REST API to update their blockchain identity entry.
Yes, that API is being worked on right now, so your comments are definitely helpful, and you're also very much welcome to provide any and all other feedback. Here's another great place to do it: http://dot-bit.org/forum/viewtopic.php?f=5&t=1423
Thanks again for your fantastic feedback! (What a wonderful Xmas present! :)
[1] https://github.com/feross/webtorrent
Isn't the same problem than with CA then?
Most people wont have their own server or have someone they trust have one.
Isn't something like Confluence more interesting on this point of view?
Most people wont have their own server or have someone they trust have one.
Isn't something like Confluence more interesting on this point of view?
Isn't the same problem than with CA then?
Well, it starts out similar to that problem, and the quote I gave above acknowledges and addresses that. It's not the same problem, though. Running your own CA today, and having it accepted by everyone else, is not simple (almost impossible), even for advanced users.
Most people wont have their own server or have someone they trust have one.
You sure about that? I see a one-click business opportunity for someone here. :)
Isn't something like Confluence more interesting on this point of view?
You mean Convergence? Have a look at section 4 in the paper which discusses the issues with that: "Existing attempts to fix this problem"
Well, it starts out similar to that problem, and the quote I gave above acknowledges and addresses that. It's not the same problem, though. Running your own CA today, and having it accepted by everyone else, is not simple (almost impossible), even for advanced users.
Most people wont have their own server or have someone they trust have one.
You sure about that? I see a one-click business opportunity for someone here. :)
Isn't something like Confluence more interesting on this point of view?
You mean Convergence? Have a look at section 4 in the paper which discusses the issues with that: "Existing attempts to fix this problem"
So, it seems it's a PGP-based technique? Good.
Please note that the site and PDF describe two different, but related projects. DNSNMC, IMO, is actually the more significant of the two, while okTurtles is just one example of the type of app it makes possible. First draft of a complete DNSNMC specification and implementation is being worked on right now and will be pushed to https://github.com/okTurtles soon.
A rudimentary DNSNMC is very simple to implement in something like Nodejs. The version that will be pushed to github will be written in CoffeeScript and NodeJS. At some point my hope is to provide a version that installs easily on Linux via package managers and integrates nicely with PowerDNS.
A rudimentary DNSNMC is very simple to implement in something like Nodejs. The version that will be pushed to github will be written in CoffeeScript and NodeJS. At some point my hope is to provide a version that installs easily on Linux via package managers and integrates nicely with PowerDNS.
Namecoin and namecoin-derived systems are cool, but they tend to overlook a lot of real-world functionality provided by DNS. As used today DNS is 1) A distributed key-value storage system 2) Incredibly scalable and fault-tolerant and 3) a de-facto internet routing layer for CDNs and GSLB endpoints. Namecoin systems typically provide (1) but overlook (2) and (3), which makes it hard to consider them as viable replacements.
I think it's interesting to look at what existing entities do when faced with DNS MITM and takedowns. The various torrent searchers and anti-censorship entities just diversified the TLDs they depend upon. So when their ".com" or ".net" domain gets taken down or man-in-the-middled, they tell their users to shift to .is , .ch, .se or some other TLD with a different regulatory framework, thus avoiding a single point of failure.
If a new mechanism depends on the inconvenience of a browser extension anyway, why not automate the process people already use? For example "colmmacc.multi" could be intercepted by an extension and translated into 5 DNS requests against say SHA-2("colmmacc").[com|ch|ly|se|is] and the extension could use a simple majority quorum of the answers to defend against a tampered response. Of course it means you have to register and host your domain 5 times, but that's pretty cheap these days.
Other nice properties: works with all existing DNS security mechanisms (including DNSSEC or DNScurve), provides security against registrar or registry level tampering or compromises. Hash of the domain makes it hard for registries to block domains (they have no idea what the name is until it is popular) and also resets the clock on squatters.