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

[ArticMine]

Hi folk,

I suspect some potential problem, so i would like to ask to contact me every exchange that trade CN (especially Polo, Bittrex and Bter).
If someone is in touch with exchange operators, please let them know.


Zoidberg

X-posted from BBR thread. Seems an attack against Cryptonote coins may actually be underway?

Is there a link to actual post where crypto_zoidberg posted this?

[1714983790]

1714983790

[Chicken76]

thinks.
how long temporary security precaution？

The initial announcement was for 24 hours. We're waiting for the developers to post more details if there's anything going on that would require it to be prolonged.

[psterryl]

Edit: never mind, seems this isn't to do with the ongoing attack threat and the devs are already on top of it.

[xulescu]

Hi folk,

I suspect some potential problem, so i would like to ask to contact me every exchange that trade CN (especially Polo, Bittrex and Bter).
If someone is in touch with exchange operators, please let them know.


Zoidberg

X-posted from BBR thread. Seems an attack against Cryptonote coins may actually be underway?

Is there a link to actual post where crypto_zoidberg posted this?

Click on "Quote from: crypto_zoidberg on Today at 07:06:01 PM" at the top of the quote.

Post was removed.

[xulescu]

I've never mined any coin in my life. I am interested in mining Monero. I run Ubuntu. Is there an easy/straightforward guide on how i can set this up?

Welcome, and let me point you to http://monero.cc/getting-started/index.html

Depending on your setup, make sure to read the OP and look for a list of miners. You might have to follow their threads to get more information about how to compile, run, configure them from their own threads (if applicable).

[smooth]

Plus open checkpoints evaluated at runtime allow us to disappear off the face of the earth and a new group could still deliver checkpoints (ie. a reduction in centralisation).

The only plausible way for someone else to take over if we disappear off the face of the earth would be to also take over maintaining the software, which means they could change any public key used to verify a signature, if it were done that way.

The idea that the existing software can continue to run indefinitely and decentralized without being updated is totally implausible.

[fluffypony]

Plus open checkpoints evaluated at runtime allow us to disappear off the face of the earth and a new group could still deliver checkpoints (ie. a reduction in centralisation).

The only plausible way for someone else to take over if we disappear off the face of the earth would be to also take over maintaining the software, which means they could change any public key used to verify a signature, if it were done that way.

The idea that the existing software can continue to run indefinitely and decentralized without being updated is totally implausible.

Point. So then the checkpoints.json thing is a convenience tool more than anything else.

[smooth]

Plus open checkpoints evaluated at runtime allow us to disappear off the face of the earth and a new group could still deliver checkpoints (ie. a reduction in centralisation).

The only plausible way for someone else to take over if we disappear off the face of the earth would be to also take over maintaining the software, which means they could change any public key used to verify a signature, if it were done that way.

The idea that the existing software can continue to run indefinitely and decentralized without being updated is totally implausible.

Point. So then the checkpoints.json thing is a convenience tool more than anything else.

In any case I agree with your point that it doesn't need to be signed, especially if blockchain.bin is not signed.

[dEBRUYNE]

https://github.com/fluffypony/bitmonero/commit/014708fe71c1379af281ca9ac17e82c159e98e6d

lol

Monero devs (particular fluffypony) have no idea what they do

Any comments on this?

[rdnkjdi]

https://github.com/fluffypony/bitmonero/commit/014708fe71c1379af281ca9ac17e82c159e98e6d

lol

Monero devs (particular fluffypony) have no idea what they do

Any comments on this?

To quote the trollbox ... sexual tension  

[smooth]

https://github.com/fluffypony/bitmonero/commit/014708fe71c1379af281ca9ac17e82c159e98e6d

lol

Monero devs (particular fluffypony) have no idea what they do

Any comments on this?

https://github.com/fluffypony/bitmonero/commit/014708fe71c1379af281ca9ac17e82c159e98e6d

lol

Monero devs (particular fluffypony) have no idea what they do

fluffypony, isn't he lead dev of XMR?
Check Descryption column in row with his name here
https://privacysolutions.no/

No that is a mistake on the privacysolutions web site. Now that you've pointed it out I'm sure he will have it corrected.

fluffypony made a mistake thinking the BBR commit was a general cryptonote exploit issue.

In the current environment being a bit on edge is understandable.

I see that it has has been reverted.

[dEBRUYNE]

Thanks for clarifying!

[xulescu]

Plus open checkpoints evaluated at runtime allow us to disappear off the face of the earth and a new group could still deliver checkpoints (ie. a reduction in centralisation).

The only plausible way for someone else to take over if we disappear off the face of the earth would be to also take over maintaining the software, which means they could change any public key used to verify a signature, if it were done that way.

The idea that the existing software can continue to run indefinitely and decentralized without being updated is totally implausible.

Point. So then the checkpoints.json thing is a convenience tool more than anything else.

In any case I agree with your point that it doesn't need to be signed, especially if blockchain.bin is not signed.

My understanding is that the daemon doesn't verify the correctness of the blockchain when it's loading it from disk, and for performance reasons the intention is to keep it this way. In this case, shouldn't the daemon sign all the bin files (i.e. pool, p2p, chain)? Shouldn't it verify the blockchain if there is a problem with the signature?

I argue that automatic checkpoints should be treated the same way, not in case you guys disappear, but so that you don't have to do it manually in the future

[fluffypony]

My understanding is that the daemon doesn't verify the correctness of the blockchain when it's loading it from disk, and for performance reasons the intention is to keep it this way. In this case, shouldn't the daemon sign all the bin files (i.e. pool, p2p, chain)? Shouldn't it verify the blockchain if there is a problem with the signature?

I argue that automatic checkpoints should be treated the same way, not in case you guys disappear, but so that you don't have to do it manually in the future

It verifies checkpoints when loading off disk. It's a bad idea to treat the blockchain as a "file" (same with p2pstate and poolstate), as we have and will abstract these away from their physical files.

Checkpoints are a temporary measure that we're going to get away from eventually, so we're just doing the best we can with something we'll be stuck with for the next few years:)

[xulescu]

It verifies checkpoints when loading off disk. It's a bad idea to treat the blockchain as a "file" (same with p2pstate and poolstate), as we have and will abstract these away from their physical files.

Checkpoints are a temporary measure that we're going to get away from eventually, so we're just doing the best we can with something we'll be stuck with for the next few years:)

Well duh, my bad. If it verifies checkpoints then only the checkpoints need to be signed
Furthermore, even after abstracting, there is still going to be a file on the disk, even if that is a compact DB.
Finally, 'next few years' seems like a lot of checkpoints to me to be doing them manually.

But I understand there are other complexities involved with key management, so there definitely is a trade-off here.

[myagui]

New purse of transgenic XMR to poloniex.com a day not to account, which is why ah

Poloniex suspended XMR deposit/withdraw as a precautionary measure.
You just need to wait a bit longer, or submit a support ticket.

[smooth]

In this case, shouldn't the daemon sign all the bin files (i.e. pool, p2p, chain)? Shouldn't it verify the blockchain if there is a problem with the signature?

Maybe, but only if your security model is that the file is in a different trust domain than the daemon itself. For example, that would make it possible to store the blockchain.bin file on a cloud drive without being vulnerable to tampering there. That's possible but not really in line with how anyone is using it to my knowledge.

[smooth]

Finally, 'next few years' seems like a lot of checkpoints to me to be doing them manually.

The need for checkpoints likely will remain for quite some time (bitcoin has them as mentioned earlier) but their frequency will depend on the nature of the environment in which they operate, which will certainly evolve.

[Hatch]

Correct on checkpointing as regular (but temporary mitigation). I would kindly request that the dev team release binaries as well, to ensure that the checkpoints are further distributed. Presumably, exchanges & pools will take the checkpoints from source at regular intervals, but compiling is not accessible to the average user.

From what I understand, the dev team is working on additional preventive measures, aiming for a more permanent solution to this type of attack. This experience should also highlight the importance of a healthy (read: strong/fast) Monero mining network. An open source AMD miner is perhaps one important measure in this regard.

Reminder: There's still an open bounty to this effect, and Wolf0 has generously posted some partial code towards this goal, so someone taking up the task, will not need to start from scratch.
https://bitcointalk.org/index.php?topic=656841.0

Edit: Credits due to the community members who came up with these creative responses. Thank you!

I think sponsoring a good optimized CPU and GPU Miner would be a great initiative. It would promote mining and if you built in a 1 or 2% developer fee you would still be preferable to other 5% miners and generate operating capital to boot!

[smooth]

Important update (source code only)

We have a new update with additional precautionary checkpoints added to protect more of the existing blockchain. In addition this update adds the ability to read checkpoints from an external file. We will be distributing updated checkpoint files that will continue to protect the blockchain without the need for a full update of the daemon.

Although there has been no actual attack we consider the threat credible and are acting accordingly. We urge you to do the same.

We are however, continuing development and this update also contains some new features that will be included in the next official numbered build. As such, dependencies have changed. For example Linux dependencies:

GCC 4.7.3 or later, CMake 2.8.6 or later, Unbound 1.4.16 or later, and Boost 1.53 or later (except 1.54, more details here).

https://github.com/monero-project/bitmonero

Plain 'git pull' wont work. Unless you are doing your own modifications to the code it is probably easiest to make a new clone. If you are doing your own modifications you should know how to use git.

If you are operating a pool or other important service, or if you are solo mining, and you compile your own node, please pull master from github and upgrade ASAP. If you are not a git expert it is probably better to just create a new clone. Likewise if you have AWS images, please rebuild them with the new version.

Our recommendation for exchange is to remain frozen for external transactions. If you are still running a node, please update.

The only evidence of anomalous activity is what was reported by fluffypony. Nevertheless malicious activity may occur that is not visible until the moment of the attack.

The update is an important precaution.

Updated binaries will follow shortly.

Further measures will be taken as necessary.