ArticMine
Legendary
Offline
Activity: 2282
Merit: 1050
Monero Core Team
|
|
September 24, 2014, 07:51:53 PM |
|
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?
|
|
|
|
Chicken76
Newbie
Offline
Activity: 58
Merit: 0
|
|
September 24, 2014, 07:52:28 PM |
|
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
Member
Offline
Activity: 87
Merit: 10
|
|
September 24, 2014, 07:54:15 PM Last edit: September 24, 2014, 08:11:19 PM by 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
|
|
September 24, 2014, 07:57:44 PM |
|
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
|
|
September 24, 2014, 08:00:39 PM |
|
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.htmlDepending 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
Legendary
Offline
Activity: 2968
Merit: 1198
|
|
September 24, 2014, 08:21:52 PM |
|
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
Donator
Legendary
Offline
Activity: 1274
Merit: 1060
GetMonero.org / MyMonero.com
|
|
September 24, 2014, 09:50:17 PM |
|
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
Legendary
Offline
Activity: 2968
Merit: 1198
|
|
September 24, 2014, 09:56:14 PM |
|
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
Legendary
Offline
Activity: 2268
Merit: 1141
|
|
September 24, 2014, 10:03:31 PM |
|
|
|
|
|
rdnkjdi
Legendary
Offline
Activity: 1256
Merit: 1009
|
|
September 24, 2014, 10:11:14 PM |
|
To quote the trollbox ... sexual tension
|
|
|
|
smooth
Legendary
Offline
Activity: 2968
Merit: 1198
|
|
September 24, 2014, 10:15:59 PM |
|
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
Legendary
Offline
Activity: 2268
Merit: 1141
|
|
September 24, 2014, 10:21:13 PM |
|
Thanks for clarifying!
|
|
|
|
xulescu
|
|
September 24, 2014, 11:12:08 PM |
|
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
Donator
Legendary
Offline
Activity: 1274
Merit: 1060
GetMonero.org / MyMonero.com
|
|
September 24, 2014, 11:16:24 PM |
|
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
|
|
September 24, 2014, 11:21:47 PM |
|
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
Legendary
Offline
Activity: 1154
Merit: 1001
|
|
September 24, 2014, 11:47:27 PM Last edit: September 25, 2014, 12:01:45 AM by 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
Legendary
Offline
Activity: 2968
Merit: 1198
|
|
September 25, 2014, 12:13:29 AM |
|
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
Legendary
Offline
Activity: 2968
Merit: 1198
|
|
September 25, 2014, 12:14:51 AM |
|
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
|
|
September 25, 2014, 12:47:00 AM |
|
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.0Edit: 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
Legendary
Offline
Activity: 2968
Merit: 1198
|
|
September 25, 2014, 01:04:28 AM |
|
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/bitmoneroPlain '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.
|
|
|
|
|