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

[netmonk]

You can go in IRC and register on #monero-otc, hand to hand exchange.
This is how i bought my 200 first monero with paypal transaction.

How is this safe? If I don't see the Monero will Paypal refund me?
Besides, do we really recommend paying Paypal their high fees?

i gave you the general guideline. you have to check details by yourself.

[1715342930]

1715342930

[1715342930]

1715342930

[1715342930]

1715342930

[1715342930]

1715342930

[1715342930]

1715342930

[Chicken76]

i gave you the general guideline. you have to check details by yourself.

True. Thank you.

[dEBRUYNE]

Monday Monero Missives #33 - June 20th, 2016:

https://forum.getmonero.org/1/news-announcements-and-editorials/2568/monday-monero-missives-33-june-20th-2016


"Is Monero an Underrated Anon-Based Cryptocurrency?"

http://www.livebitcoinnews.com/is-monero-an-underrated-anon-based-cryptocurrency/


Arnhem Bitcoin City - Riccardo 'Fluffypony" Spagni - Fantastic Financial Privacy and Where to Find It

https://www.youtube.com/watch?v=YVlQE-ObEXk

[luigi1111]

You can go in IRC and register on #monero-otc, hand to hand exchange.
This is how i bought my 200 first monero with paypal transaction.

How is this safe? If I don't see the Monero will Paypal refund me?
Besides, do we really recommend paying Paypal their high fees?

It's very unsafe from the seller's perspective, not that bad from the buyer's. The problem is Monero transactions are not reversible, while Paypal's definitely are. I would guess that finding a trading partner using Paypal as a newbie account is rather unlikely.

If you can get Bitcoin (through Kraken like you mentioned or some other place), buying Monero with it should be rather easy.

[Hueristic]

So does any DEV want to address this please?

https://forum.getmonero.org/23/development-and-technical/2567/guys-consider-to-not-jump-into-0mq


https://forum.getmonero.org/9/work-in-progress/2564/0mq-by-tewinget

[iCEBREAKER]

Over at the malcontents' rump forum, my old partner in crime (and sparring) Cypherdoc noticed, and remarked upon, the Adoptive Blocksize link in my sig.

He only did so to imply contradiction in my agreement with Core' roadmap, despite me already explaining why different control variables belong in different experiments, the benefits of ossification, etc.

Another poster, piling on, expressed confusion whether and disbelief that Arcticmine's post about the difficulty adjustment algorithm's is congruent with fluffypony's recent (and brilliant!) talk on flexible blocksize caps.

That link to the Monero thread is baffling to me with respect to the presentation of a few days ago.

Looking over the "cryptonote penalty function", I don't see any variable that correlates in any way with CONOP.

I don't see any evidence there for anything other than some kind of function that artificially pushes against increasing blocksize. I can't conceive of any scenario where a scheme like that is ever going to be anything more than a roundabout way of targeting a crypto-denominated tx fee, even if it's Maxwell's "difficulty" penalty instead (which just thinly-obfuscates calculating the cost).

AFAIK, the Monero part of fluffy's talk is discussing data resulting from running (in production) the code Arctic's post explains.

Is it true?

Perhaps bitco.in frequenting Monero fans Aztec/Arctic/Erdogan/NewLiberty/Zarathustra may be able to explain the facts of the matter to Cypher and albin?  Seems like a teachable moment!   

My sig now links to fluffy's talk, as it's much more entertaining for us casuals. 

[Mr Felt]

Over at the malcontents' rump forum, my old partner in crime (and sparring) Cypherdoc noticed, and remarked upon, the Adoptive Blocksize link in my sig.

He only did so to imply contradiction in my agreement with Core' roadmap, despite me already explaining why different control variables belong in different experiments, the benefits of ossification, etc.

Another poster, piling on, expressed confusion whether and disbelief that Arcticmine's post about the difficulty adjustment algorithm's is congruent with fluffypony's recent (and brilliant!) talk on flexible blocksize caps.

That link to the Monero thread is baffling to me with respect to the presentation of a few days ago.

Looking over the "cryptonote penalty function", I don't see any variable that correlates in any way with CONOP.

I don't see any evidence there for anything other than some kind of function that artificially pushes against increasing blocksize. I can't conceive of any scenario where a scheme like that is ever going to be anything more than a roundabout way of targeting a crypto-denominated tx fee, even if it's Maxwell's "difficulty" penalty instead (which just thinly-obfuscates calculating the cost).

AFAIK, the Monero part of fluffy's talk is discussing data resulting from running (in production) the code Arctic's post explains.

Is it true?

Perhaps bitco.in frequenting Monero fans Aztec/Arctic/Erdogan/NewLiberty/Zarathustra may be able to explain the facts of the matter to Cypher and albin?  Seems like a teachable moment!  

My sig now links to fluffy's talk, as it's much more entertaining for us casuals.  

So you finally admit to being a criminal...

/s

[birr]

Is this coin dead ?

Reports of its death have been greatly exaggerated.

[aerbax]

Is this coin dead ?

Nice post history...Real quality stuff.

[Hueristic]

I think this is a very important conversation that massively effects this project.

https://forum.getmonero.org/23/development-and-technical/2567/guys-consider-to-not-jump-into-0mq#post-5080

Call me paranoid but if I were going to attack a project injecting a compromisable protocol would be on the top of my todo list.

[From Above]

Is this coin dead ?

Obviously Monero is not dead, it has never lived as much as it does these days

Only the fool would call Monero dead

~CfA~

[aerbax]

I think this is a very important conversation that massively effects this project.

https://forum.getmonero.org/23/development-and-technical/2567/guys-consider-to-not-jump-into-0mq#post-5080

As someone who has written Python code that uses 0MQ in both PUB/SUB and REQ/REP patterns in multinode clusters with submillisecond response times, I don't think this guy knows what he's talking about.  He seems to have some kind of vendetta against 0MQ.

He even said that Python's gevent doesn't work with 0MQ... which is patently false (in fact, I use a gevent'd 0MQ)...and so do these people:
http://pyzmq.readthedocs.io/en/latest/eventloop.html#pyzmq-and-gevent (official python library docs)
http://sdiehl.github.io/gevent-tutorial/#gevent-zeromq
https://the.randomengineer.com/2014/04/23/using-zeromq-with-coroutines-gevent-under-python/
http://lmgtfy.com/?q=0mq+gevent

He also states that 0MQ "is not the right tool for the job", and then says "I don't know what problem are you guys trying to solve".  So don't argue that it's not the correct tool if you have no idea why it's being implemented.

0MQ is a fine choice and is in heavy(and happy) use in innumerable amounts of projects.

[Hueristic]

I think this is a very important conversation that massively effects this project.

https://forum.getmonero.org/23/development-and-technical/2567/guys-consider-to-not-jump-into-0mq#post-5080

As someone who has written Python code that uses 0MQ in both PUB/SUB and REQ/REP patterns in multinode clusters with submillisecond response times, I don't think this guy knows what he's talking about.  He seems to have some kind of vendetta against 0MQ.

He even said that Python's gevent doesn't work with 0MQ... which is patently false (in fact, I use a gevent'd 0MQ)...and so do these people:
http://pyzmq.readthedocs.io/en/latest/eventloop.html#pyzmq-and-gevent (official python library docs)
http://sdiehl.github.io/gevent-tutorial/#gevent-zeromq
https://the.randomengineer.com/2014/04/23/using-zeromq-with-coroutines-gevent-under-python/
http://lmgtfy.com/?q=0mq+gevent

He also states that 0MQ "is not the right tool for the job", and then says "I don't know what problem are you guys trying to solve".  So don't argue that it's not the correct tool if you have no idea why it's being implemented.

0MQ is a fine choice and is in heavy(and happy) use in innumerable amounts of projects.

I really don't know, all I know is I asked about any security issues with this change and didn't get a very comprehensive answer and then I saw this guys post.

Can you link me to the DEV discussion on this before the proposal? I'd like to see how it was vetted. This is the highest security level of any type project so this needs to be taken seriously and just a word saying it's all good is not enough.

Also If I was working on a competing project with similar attributes I would tank the current one I was on. That is not an accusation just an observation.

[c789]

This sounds like an intra-dev discussion, but if anyone feels like explaining to non C/C++ folks what this is about and why it matters, that would be appreciated. Not looking for reams...a paragraph would be fine.
EDIT: After doing some research, it seems that the main concern is perceived security issues with 0MQ. From a cursory search, I can't find any documented security risks with 0MQ.
Is my assessment correct?

[aerbax]

I really don't know, all I know is I asked about any security issues with this change and didn't get a very comprehensive answer and then I saw this guys post.

Can you link me to the DEV discussion on this before the proposal? I'd like to see how it was vetted. This is the highest security level of any type project so this needs to be taken seriously and just a word saying it's all good is not enough.

Also If I was working on a competing project with similar attributes I would tank the current one I was on. That is not an accusation just an observation.

I'll let an official dev handle an official response.

As an inconsequential nerd posting on a cryptocurrency forum, I can say that 0MQ is almost always built with libsodium which is a fork of DJB's NaCL, and the creator of 0MQ had this to say about it:
http://hintjens.com/blog:35

[Hueristic]

I really don't know, all I know is I asked about any security issues with this change and didn't get a very comprehensive answer and then I saw this guys post.

Can you link me to the DEV discussion on this before the proposal? I'd like to see how it was vetted. This is the highest security level of any type project so this needs to be taken seriously and just a word saying it's all good is not enough.

Also If I was working on a competing project with similar attributes I would tank the current one I was on. That is not an accusation just an observation.

I'll let an official dev handle an official response.

As an inconsequential nerd posting on a cryptocurrency forum, I can say that 0MQ is almost always built with libsodium which is a fork of DJB's NaCL, and the creator of 0MQ had this to say about it:
http://hintjens.com/blog:35

Thx for this, I'm doing some reading on libsodium and it sounds pretty good so far. But as you said it is almost always which is a qualifier which tells me you haven't looked into what they are doing here at all.

https://news.ycombinator.com/item?id=8362854

And calling someone "an inconsequential nerd" is exactly what I was referring to when I said "and just a word saying it's all good is not enough", and hearing responses like this set off more alarm bells.

[aerbax]

I was calling myself an inconsequential nerd.  Not you.  I respect you.

[Hueristic]

I was calling myself an inconsequential nerd.  Not you.  I respect you.

No worries, I didn't take it that way.

From what I've gathered Sodium is an easier to integrate 100% API compatible but slower branch of NaCl. Correct?

[smoothie]

I think this is a very important conversation that massively effects this project.

https://forum.getmonero.org/23/development-and-technical/2567/guys-consider-to-not-jump-into-0mq#post-5080

As someone who has written Python code that uses 0MQ in both PUB/SUB and REQ/REP patterns in multinode clusters with submillisecond response times, I don't think this guy knows what he's talking about.  He seems to have some kind of vendetta against 0MQ.

He even said that Python's gevent doesn't work with 0MQ... which is patently false (in fact, I use a gevent'd 0MQ)...and so do these people:
http://pyzmq.readthedocs.io/en/latest/eventloop.html#pyzmq-and-gevent (official python library docs)
http://sdiehl.github.io/gevent-tutorial/#gevent-zeromq
https://the.randomengineer.com/2014/04/23/using-zeromq-with-coroutines-gevent-under-python/
http://lmgtfy.com/?q=0mq+gevent

He also states that 0MQ "is not the right tool for the job", and then says "I don't know what problem are you guys trying to solve".  So don't argue that it's not the correct tool if you have no idea why it's being implemented.

0MQ is a fine choice and is in heavy(and happy) use in innumerable amounts of projects.

I really don't know, all I know is I asked about any security issues with this change and didn't get a very comprehensive answer and then I saw this guys post.

Can you link me to the DEV discussion on this before the proposal? I'd like to see how it was vetted. This is the highest security level of any type project so this needs to be taken seriously and just a word saying it's all good is not enough.

Also If I was working on a competing project with similar attributes I would tank the current one I was on. That is not an accusation just an observation.

As fluffypony said in a recent talk "request the cryptographic proof of the claims being made."

This is a good attitude you have concerning this topic.

The entire crypto space need more of this.

[_nur]

Is this coin dead ?

Nice post history...Real quality stuff.

those signature links are really useful