Topic: [XMR] Monero - A secure, private, untraceable cryptocurrency - page 1394. (Read 4671575 times)

Weird, I would have picked some other words to indicate success.
Such as:
"We will be distributing updated checkpoint files that will continue to protect the blockchain without the need for a full update of the daemon."

This has been done exactly never before on other coins.
It shows the innovation on demand this team can produce, with rapid on-point responsiveness to a real-time threat with no warning, whether it be real or not.

They could be writing anything, anywhere, and yet have chosen to work on this project.
I am humbled by their generosity to advancing the state of the art as we know it in this arena.

Thank you gentlemen, thank you kindly, you are a credit to your profession.

Dear Monero

Can I have have access to my fucking money yet??

phantom attack: success

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:


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.

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!

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.

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.

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

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.

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

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

Thanks for clarifying!

To quote the trollbox ... sexual tension  

Any comments on this?

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

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

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.

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).

Post was removed.