[XMR] Monero - A secure, private, untraceable cryptocurrency

[Azael]

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.

[aerbax]

Actually I don't know who's better between Dash or Monero and I know there is heated debate ...

This one is easy.

How do you like your privacy?  Adequate or the best available?

And as a followup, how do you feel about rich lists?  Is it troubling at all to be able to see the amount of coins available on a given address?  Do you see a way in which this information could be used to extort?

[Gillette]

Several months back vcash`s john connor was bragging he found some weaknesses in xmr. Was he finally able to produce the proofs?

[Monerobuyer0]

Several months back vcash`s john connor was bragging he found some weaknesses in xmr. Was he finally able to produce the proofs?

There was a lot of FUD spewed with a goal of getting the monero price down.  There wasnt anything behind it.  If there was, they would have attacked monero already, given how much they hate it and view it as a competitor.

[iCEBREAKER]

Several months back vcash`s john connor was bragging he found some weaknesses in xmr. Was he finally able to produce the proofs?

John Conman will demonstrate the claimed weaknesses, just as soon as he finishes proving he didn't get caught stealing/obfuscating code from Bitcoin.

Any minute now....

[skeleton_keyboard.gif]

 

[c789]

Actually I don't know who's better between Dash or Monero and I know there is heated debate ...

This one is easy.

How do you like your privacy?  Adequate or the best available?

And as a followup, how do you feel about rich lists?  Is it troubling at all to be able to see the amount of coins available on a given address?  Do you see a way in which this information could be used to extort?

Yep. And then there's the traceability risk. If the same entity owns the series of masternodes used to process the dash transaction, then that entity can trace the transaction. It would mean nothing to a big govt's budget to drop $50k or more to buy up masternodes for this purpose. Maybe they've already done it. This can't happen with XMR since it's fully decentralized and untraceable. Sorry to all who've seen me state this many times but if the topic gets brought up by someone who doesn't seem to know, I'll most likely say it again.

[Hueristic]

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/richlist

[TechorMarketing]

Well just looking at XMR's rich list should tell you something.

http://moneroblocks.info/richlist

I know a lot of people. None of them will ever be on the Monero richlist:)

[smoothie]

Well just looking at XMR's rich list should tell you something.

http://moneroblocks.info/richlist

I know a lot of people. None of them will ever be on the Monero richlist:)

I love this inside joke. "Monero richlist"....

Having those two words in the same sentence is an oxymoron. 

[smoothie]

I figured I would make a short post about this here given it is an item that has perplexed me a bit (not sure if I'm reading into it the wrong way or not).

The output index (local to the transaction and not the global index) when being written to a file given its type is of size_t is output in hex format.

The way I've known this is that if the real_output_index is 10 or higher it starts to utilize hex characters.

Like 10 = a, 11 = b, 12 = c, etc.

And I just found that odd that when I've written that value to a file or even output to the command line that it shows up in hex.

This is dealing with the portion of the code that does key_image generation.

What I found even more odd is a random loop variable like (for int i = 0...) when outputting i also gets output in hex as well.

Something that perplexed me as i is an integer and not type size_t. So I must be missing something.

I've kind of had to work around it when I run into indexes above 9 that get retrieved for key_image generation.

It's not a huge deal just an interesting oddity I never could figure out while writing the software for the physical coins I've recently released.

[Hueristic]

I figured I would make a short post about this here given it is an item that has perplexed me a bit (not sure if I'm reading into it the wrong way or not).

The output index (local to the transaction and not the global index) when being written to a file given its type is of size_t is output in hex format.

The way I've known this is that if the real_output_index is 10 or higher it starts to utilize hex characters.

Like 10 = a, 11 = b, 12 = c, etc.

And I just found that odd that when I've written that value to a file or even output to the command line that it shows up in hex.

This is dealing with the portion of the code that does key_image generation.

What I found even more odd is a random loop variable like (for int i = 0...) when outputting i also gets output in hex as well.

Something that perplexed me as i is an integer and not type size_t. So I must be missing something.

I've kind of had to work around it when I run into indexes above 9 that get retrieved for key_image generation.

It's not a huge deal just an interesting oddity I never could figure out while writing the software for the physical coins I've recently released.

Must be from where it's inherited from. I don't know the code but this may help.
https://github.com/monero-project/bitmonero/search?utf8=%E2%9C%93&q=real_output_index+

Code:

  bool generate_key_image_helper(const account_keys& ack, const crypto::public_key& tx_public_key, size_t real_output_index, keypair& in_ephemeral, crypto::key_image& ki);
  void get_blob_hash(const blobdata& blob, crypto::hash& res);

[fluffypony]

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.

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.

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.

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.

[fluffypony]

We hit 100% on StackExchange, well done!



You're still able to commit and join the private beta, even when it's started: http://area51.stackexchange.com/proposals/98617/monero

[birr]

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/richlist

It could be worse, but there's a hint of smugness to the writing on that page.

[luigi1111]

I figured I would make a short post about this here given it is an item that has perplexed me a bit (not sure if I'm reading into it the wrong way or not).

The output index (local to the transaction and not the global index) when being written to a file given its type is of size_t is output in hex format.

The way I've known this is that if the real_output_index is 10 or higher it starts to utilize hex characters.

Like 10 = a, 11 = b, 12 = c, etc.

And I just found that odd that when I've written that value to a file or even output to the command line that it shows up in hex.

This is dealing with the portion of the code that does key_image generation.

What I found even more odd is a random loop variable like (for int i = 0...) when outputting i also gets output in hex as well.

Something that perplexed me as i is an integer and not type size_t. So I must be missing something.

I've kind of had to work around it when I run into indexes above 9 that get retrieved for key_image generation.

It's not a huge deal just an interesting oddity I never could figure out while writing the software for the physical coins I've recently released.

size_t is an (unsigned) integer as well.

How are you outputting these to a file?

[Hueristic]

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:encryption

ZeroMQ 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/

CURVE - secure authentication and encryption based on elliptic curve cryptography, using the Curve25519 algorithm from Daniel Bernstein and based on CurveCP's security handshake. See http://rfc.zeromq.org/spec:25, http://rfc.zeromq.org/spec:26, and http://curvecp.org.

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/richlist

It 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?

[birr]

Why write?
Good English should engage the reader.
Writing what makes you feel good is as easy as it's ineffectual.

[Hueristic]

Why write?
Good English should engage the reader.
Writing what makes you feel good is as easy as it's ineffectual.

It's a JOKE!

[smoothie]

I figured I would make a short post about this here given it is an item that has perplexed me a bit (not sure if I'm reading into it the wrong way or not).

The output index (local to the transaction and not the global index) when being written to a file given its type is of size_t is output in hex format.

The way I've known this is that if the real_output_index is 10 or higher it starts to utilize hex characters.

Like 10 = a, 11 = b, 12 = c, etc.

And I just found that odd that when I've written that value to a file or even output to the command line that it shows up in hex.

This is dealing with the portion of the code that does key_image generation.

What I found even more odd is a random loop variable like (for int i = 0...) when outputting i also gets output in hex as well.

Something that perplexed me as i is an integer and not type size_t. So I must be missing something.

I've kind of had to work around it when I run into indexes above 9 that get retrieved for key_image generation.

It's not a huge deal just an interesting oddity I never could figure out while writing the software for the physical coins I've recently released.

size_t is an (unsigned) integer as well.

How are you outputting these to a file?

ofstream

Same result for std out as well.

[smoothie]

Must be from where it's inherited from. I don't know the code but this may help.
https://github.com/monero-project/bitmonero/search?utf8=%E2%9C%93&q=real_output_index+

Code:

  bool generate_key_image_helper(const account_keys& ack, const crypto::public_key& tx_public_key, size_t real_output_index, keypair& in_ephemeral, crypto::key_image& ki);
  void get_blob_hash(const blobdata& blob, crypto::hash& res);

Yes that is the same function header to the function where real_output_index is referenced in relation to calculating key images.