And I thought that this was replacing remote communication as well. Which is a VERY BIG DEAL. But after listening to the Podcast you linked I see that it is intended for interprocess communication currently but Fluffy did say it can be extended for wiring protocol replacement.
In terms of "dev notes", a lot of this stuff goes down on IRC in #monero-dev and sometimes even #monero. The bi-weekly dev meetings are the culmination of these discussions that span thousands of lines of text over many days.
Could you post those logs on pastebin?
0MQ is a trivial decision to make, because it's a backend change as you've observed. Our only option is either a messaging system (of which 0MQ is unequivocally the most battle-tested, with the largest number of implementations) or replacing the current HTTP server with something far more performant. Obviously, short of forking nginx, the latter is not really an option.
I don't quite understand why there needs to be any wrapper at all for local communication, why not use direct input and add the daemon functionality to say the gui? Is there any reason these need to be separate for end users? I just see this as a injection point where one doesn't need to be.To speak to your other concern: we are definitely looking at replacing the wire protocol. Since we'll have 0MQ in already, and since we want to enable developers to build consensus-compatible implementations in whatever language they'd like, the logical choice is ZMTP (
http://zmtp.org). This is, again, something that is battle-hardened and has implementations in tons of languages. Our other option is picking one of the Tor pluggable transports, something like obfs4, but that's somewhat less desirable for cross-implementation purposes.
I do remember this discussion being touched on in this thread I think but I don't remember a decision being announced. Making the product more accessible to a larger is base is laudable as I said I just want to make sure it is not at the cost of security. Especially with the vultures hovering looking for any attack vector they can find.
The current home-grown Boost::ASIO wire protocol is significantly more risky than switching to something that is standard. It's entirely possible that there's some weirdness under the hood that we haven't uncovered yet, so swapping it out for something that is well-known and widely used in FOSS projects is extremely desirable. Complexity is the enemy of good security, and in this case custom protocols way worse than well-known standards.
Perhaps more importantly, though, the wire protocol is hardly an attack surface. The major risk it represents is an MITM attack revealing what transactions you were the first to broadcast (mitigated by end-to-end encryption in ZMTP), and fingerprinting attacks being able to correlate your clearnet IP with your i2p address (mitigated by introducing some execution randomness to the i2p connectivity, and completely separating the information shared with nodes on both interfaces). Beyond that, a compromised or poisoned wire protocol won't be able to "do" anything particularly bad. The daemon has no idea what your private keys are. It has some information about your transactions you send out, and the ones you're interested in, but if it were revealing that it would be spotted very quickly.
This is actually my top concern, I want to see how this has been vetted. Call me paranoid but changing a core protocol with off hand remarks is worrisome and I just want to verify that we are not just taking anyone's word on the fact that the crypto in 0MQ is sound and safe when it comes to a currency that cannot be checked for manipulation.
http://arstechnica.com/security/2014/01/how-the-nsa-may-have-put-a-backdoor-in-rsas-cryptography-a-technical-primer/BTW we are very close to losing beta status correct? How long will this be tested within the beta phase?
I don't know anything about this so I wanted to see a peer review or a word from our scientists that they have verified this is bulletproof.
Looking into ZeroMq I see it uses Curve25519 correct?
http://zeromq.org/topics:encryptionZeroMQ 4.x has extensible encryption, and comes with CurveZMQ as a built-in security mechanism. Pieter Hintjens has some articles that explain how this works. The only extra dependency is libsodium, which provides the Curve25519 security functions.
https://www.reddit.com/r/programming/comments/1ms5fu/new_zeromq_4_does_strong_encryption_and_perfect/https://en.wikipedia.org/wiki/Curve25519
I no longer trust the constants. I believe the NSA has manipulated them through their relationships with industry
Bruce Schneier, The NSA Is Breaking Most Encryption on the Internet (2013)
***********************************************************************************************************
Will Monero pitch to Anchor into Factom blockchain after they do Ethereum?
Ethereum is for smart contracts Factom is for data and Dash or Monero is for privacy.
Actually I don't know who's better between Dash or Monero and I know there is heated debate about this so not opening that pandoras box because I don't have a horse in the race. Anyway both are experimental technologies in field worthy of pursuit.
Well just looking at XMR's rich list should tell you something.
http://moneroblocks.info/richlistIt could be worse, but there's a hint of smugness to the writing on that page.
As there should be, this project is headed by some of the smartest and capable people I've ever seen, they are so advanced they take for granted that we as a community know the things I ask in this thread. I feel like the kid in class that asked the question because others are lost and afraid to. Not to say I don't get lost, my brain is on life support these days. Lol
This project gets the hardest scrutiny and has never to my knowledge lied, misled or deceived the community, how many other ones can you say that about?
Still waiting on a reply here.
