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

[smooth]

This coin sounds pretty cool.
Can someone explain ring signatures to me?

Thanks

Ring signatures mean that when you sign a tranaction to spend an output (coins), no one looking at the block chain can tell whether you signed it or one of the other outputs you choose to mix in with yours. With a mixing factor of 5 or 10 after several transactions there are millions of possible coins all mixed together. You get "anonymity" and mixing without having to use a third party mixer.

There are a number of other anonymity features, explained in the first post on this thread and the pages linked from there.

[smooth]

What was the command line to upgrade the linux version ?

Easiest thing to do is

1. Securely back up your wallets

2. Rename your source+build tree. (I'd say delete but I don't want people deleting their wallets when they ignored #1)

3. rm -r ~/.bitmonero (possibly-poisoned block chain is in here)
 
4. Follow the directions in the first post to do a fresh git clone and compile.

[smooth]

Is this coin bitmonero?
Can this coin be merge mined with fantomcoin? What hashrate do you get with the fantomcoin merge miner?

Bitmonero may be forked soon but until now it is the same.

Yes you can merge mine both fantomcoin & Monero BUT you have to use an other miner that is 6 times slower than the one to mine Monero alone.

It is not worth it, you'll lose too much hashrate and fantomcoin has no value.

your right. I am getting 4 times slowing mining and only mining 2 coins at once. It is not worth it.

I tried the merged miner and it didn't even work. Mined fantom just fine but any MRO blocks it found resulted in unspendable coins.

This is not FUD, just my experience. If someone were to figure out how to fix the merged miner I would use it.

[pwrz]

Just making sure - is the healthy blockchain in the OP?

[eizh]

Windows binaries have been uploaded. Everything in the OP now has the security fix. I'll upload blockchains soon (check for May 8th date).

[superresistant]

Windows binaries have been uploaded. Everything in the OP now has the security fix. I'll upload blockchains soon (check for May 8th date).

Please provide an additional dropbox link.

[smooth]

Just making sure - is the healthy blockchain in the OP?

Blockchain download is being updated (the old link was removed). If you use the current build from OP you can sync yourself, or wait for the updated blockchain download.

[emontmon]

HOPE you don't fork over weekend. I am out of town.

[AnonyMint]

There are at least two critically necessary improvements needed to the CryptoNote anonymity algorithm to make it function well in the real world. I am withholding my ideas until I see a coin that has an extremely capable Benevolent Dictator For Life (none of this Foundation and communism BS that has wrecked Bitcoin), a premine to fund contributions, and partial open source to prevent a plethora of clones in the ramp up phase.

Upthread I have alluded to other improvements (e.g. CPU only, better IP obfuscation than Tor and I2P, pools that force decentralization, one click mining for the masses, etc) to which I implied I know of the solutions to. I have stated what I want to see in order to offer my support.

If you think you can win with what you have now, I think you are mistaken.

Good luck.

[Ivan166]

Windows binaries have been uploaded. Everything in the OP now has the security fix. I'll upload blockchains soon (check for May 8th date).

Russian thread updated.

[SlyWax]

Can you explain how someone could corrupt the block chain ?
If I'm synced with the network, then the checkpoint won't affect me since they are in the past.
And I won't accept changing old blocks.

So you should explain us how the checkpoint corrupted the blockchain, and how to check for a good or bad one.

Is'nt there a command to recheck the entire blockchain, without having to download it ?
If not, it is needed.

[smooth]

Can you explain how someone could corrupt the block chain ?
If I'm synced with the network, then the checkpoint won't affect me since they are in the past.
And I won't accept changing old blocks.

So you should explain us how the checkpoint corrupted the blockchain, and how to check for a good or bad one.

Is'nt there a command to recheck the entire blockchain, without having to download it ?
If not, it is needed.

If you had a full chain, it very likely was never corrupted. (Of course there could always be bugs but we don't know of any that would do this.)

If you had tried to sync after the checkpoint was added, the code could have accepted some earlier blocks (before the checkpoint) without fully validating them.

If you downloaded a valid blockchain file (which would have included all of the blocks up to the checkpoint) and used the code version with the checkpoint, you were in all likelyhood not affected, other than some invalid blocks being accepted by your node (but offchain), bloating your memory and disk usage. This could have eventually become a denial-of-service issue, if the number of invalid blocks continued to grow.

There were probably very few people directly affected.

But when it comes to the integrity of the blockchain it does not pay to take chances. So the checkpoint has been temporarily removed forcing all blocks to be fully validated and will likely soon be added back in a safer way.

A command to validate the existing block chain is a good idea. We will look at that, possibly in connection with the improved checkpoint feature.

[equipoise]

I tried to build optimized executables from the first time I start mining with the not optimized ones. Finally I built windows optimized executables (check points removed!). Those are up to three times faster on my 3rd gen core i7 then the previous optimized ones (see the bold text bellow before reading it all – you may want to skip it).
Here is the process I used to build them:
1) built boost 1_55
set intel variables:

Code:

"C:\Program Files (x86)\Intel\Composer XE 2013 SP1\bin\ipsxe-comp-vars.bat" intel64

for 3rd gen i7 i5 i3:

Code:

b2 variant=release address-model=64 instruction-set=core-avx-i toolset=intel --build-type=complete --with-system --with-filesystem --with-thread --with-date_time --with-chrono --with-regex --with-serialization --with-atomic --with-program_options stage

for 2nd gen i7 i5 i3:

Code:

b2 variant=release address-model=64 instruction-set=corei7-avx toolset=intel --build-type=complete --with-system --with-filesystem --with-thread --with-date_time --with-chrono --with-regex --with-serialization --with-atomic --with-program_options stage

for previous gen i7 i5 i3:

Code:

b2 variant=release address-model=64 instruction-set=corei7 toolset=intel --build-type=complete --with-system --with-filesystem --with-thread --with-date_time --with-chrono --with-regex --with-serialization --with-atomic --with-program_options stage

for pentium-m (SSE3) intel processors:

Code:

b2 variant=release address-model=64 instruction-set=pentium-m toolset=intel --build-type=complete --with-system --with-filesystem --with-thread --with-date_time --with-chrono --with-regex --with-serialization --with-atomic --with-program_options stage

2) create the msvc project with cmake as specified in the op
3) open the project in msvc and select Release instead of Debug
4) right click on project external -> upnpc-static -> Intel Composer XE SP1 -> Intell C++. Same with those projects: comman, crypto, cryptonote_core, rpc, daemon
5) setting the same options for all those projects (right click -> properties) (https://www.dropbox.com/s/5l3t5gysk4uhu7n/screenshots_intel_options.rar).
6) copy all boost files starting with libboost_ and ending on -iw-mt-s-1_55.lib to the build\src\Release folder
7) right click on daemon -> properties -> linker -> input -> additional dependencies and set those to:

Code:

Release\libboost_serialization-iw-mt-s-1_55.lib;Release\libboost_program_options-iw-mt-s-1_55.lib;Release\libboost_atomic-iw-mt-s-1_55.lib;C:\Program Files (x86)\Intel\Composer XE 2013 SP1\compiler\lib\intel64\libmatmul.lib;C:\Program Files (x86)\Intel\Composer XE 2013 SP1\ipp\lib\intel64\ippcore.lib;C:\Program Files (x86)\Intel\Composer XE 2013 SP1\ipp\lib\intel64\ippvm.lib;C:\Program Files (x86)\Intel\Composer XE 2013 SP1\ipp\lib\intel64\ipps.lib;C:\Program Files (x86)\Intel\Composer XE 2013 SP1\compiler\lib\intel64\libiompstubs5md.lib;Release\libboost_regex-iw-mt-s-1_55.lib;Release\libboost_filesystem-iw-mt-s-1_55.lib;Release\libboost_chrono-iw-mt-s-1_55.lib;Release\libboost_system-iw-mt-s-1_55.lib;Release\libboost_date_time-iw-mt-s-1_55.lib;C:\Program Files (x86)\Intel\Composer XE 2013 SP1\compiler\lib\intel64\libdecimal.lib;C:\Program Files (x86)\Intel\Composer XE 2013 SP1\compiler\lib\intel64\svml_dispmt.lib;C:\Program Files (x86)\Intel\Composer XE 2013 SP1\compiler\lib\intel64\libirc.lib;C:\Program Files (x86)\Intel\Composer XE 2013 SP1\compiler\lib\intel64\libmmt.lib;kernel32.lib;user32.lib;gdi32.lib;winspool.lib;shell32.lib;ole32.lib;oleaut32.lib;uuid.lib;comdlg32.lib;advapi32.lib;Release\rpc.lib;Release\libboost_thread-iw-mt-s-1_55.lib;Release\cryptonote_core.lib;Release\crypto.lib;Release\common.lib;..\external\miniupnpc\Release\miniupnpc.lib;ws2_32.lib;iphlpapi.lib

Build
In the build there was some errors with the Intel compiler. Some of those were with Lambda Expression. Those are fixed this way: instead "() {}" it's "() -> bool {}"
There were some declaration errors. Those were fixed this way: instead "someclass foo = somefunction(foo);" it's "someclass foo; foo = somefunction(foo);". I'm not sure if there were other errors, because I didn't kept track of those. There are huge amount of warnings, but I ignored all of them.
9) ReBuild again and again until no errors are present.
I only tested the 3rd gen and Pentium M versions. The Pentium M is actually faster on my 3rd gen!? NoodleDoodle told me in irc that I don't need AVX, but just SSE3, but I decided to test it anyway (just to lose 6 more hours). Those executables may need libiomp5md.dll in the same folder in order to tun (needed for the 3rd gen executable not sure for the pentium-m. it's included in the archive). The only problem with those executables is that they don’t want to synchronize with the blockchain so they can’t be used.
Tip me some MRO: 4AyRmUcxzefB5quumzK3HNE4zmCiGc8vhG6fE1oJpGVyVZF7fvDgSpt3MzgLfQ6Q1719xQhmfkM9Z2u NXgDMqYhjJVmc6KX
Also I want to buy 0.02623544 BTC worth of MRO. Someone?

[smooth]

So tldr does this work or not?

I will tip you some MRO regardless. Trying things even if they don't work is still useful.

[eizh]

Important

(Big scary red letters because it really is important.)

First, get the newest builds (all fully updated on the OP).

Second, unless your blockchain.bin predates the May 3rd update, you should delete it and download the latest from the OP and replace yours. You might have saved it and overridden it after May 3rd and that's fine. However, a full sync starting from the genesis block after the May 3rd update may have partially corrupted your blockchain. Clean blockchains have been uploaded for 64-bit Windows and 64-bit Linux/OSX. 32-bit versions don't exist because it was added recently. If you're unsure of when your blockchain dates from, update it.

The attack works by flooding the network with low height (i.e. early) blocks. They would normally be added as alternates but if you're in the process of synching, they might get added as real blocks. This is because the checkpointing in the BCN code is not done well and it doesn't validate the headers of pre-checkpoint blocks. The number of people affected probably isn't that big but we can't have inconsistency in the network.

Because the attack is ongoing, if you resync from scratch you'll grab a few of these invalid blocks (about 1 in every ~500 blocks) so you'll still have a slightly corrupted chain. Update from the OP with the latest builds and chains and you'll be clean and protected. In the future, better checkpointing will be implemented but until then it won't be used.

[trogdorjw73]

Important

(Big scary red letters because it really is important.)

First, get the newest builds (all fully updated on the OP).

Second, unless your blockchain.bin predates the May 3rd update, you should delete it and download the latest from the OP and replace yours. You might have saved it and overridden it after May 3rd and that's fine. However, a full sync starting from the genesis block after the May 3rd update may have partially corrupted your blockchain. Clean blockchains have been uploaded for 64-bit Windows and 64-bit Linux/OSX. 32-bit versions don't exist because it was added recently. If you're unsure of when your blockchain dates from, update it.

The attack works by flooding the network with low height (i.e. early) blocks. They would normally be added as alternates but if you're in the process of synching, they might get added as real blocks. This is because the checkpointing in the BCN code is not done well and it doesn't validate the headers of pre-checkpoint blocks. The number of people affected probably isn't that big but we can't have inconsistency in the network.

Because the attack is ongoing, if you resync from scratch you'll grab a few of these invalid blocks (about 1 in every ~500 blocks) so you'll still have a slightly corrupted chain. Update from the OP with the latest builds and chains and you'll be clean and protected. In the future, better checkpointing will be implemented but until then it won't be used.

Question: I did not update any of my miners with any of the new builds (e.g. with checkpointing) in the past day or two -- everything I have is from around May 4/5 I think. Does that mean my nodes are clean, or do I have to clear them all out, grab the latest version, and resync on all systems? My PC right now *thinks* it's mining, and it had at least through block 28000 or so prior to these attacks, so I should be safe, right? Will updating at this point benefit me or am I just asking for trouble? (It would be great to add a "version" command in the wallet and daemon -- provided of course that each new build remembers to update the version number.)

[smooth]

Important

(Big scary red letters because it really is important.)

First, get the newest builds (all fully updated on the OP).

Second, unless your blockchain.bin predates the May 3rd update, you should delete it and download the latest from the OP and replace yours. You might have saved it and overridden it after May 3rd and that's fine. However, a full sync starting from the genesis block after the May 3rd update may have partially corrupted your blockchain. Clean blockchains have been uploaded for 64-bit Windows and 64-bit Linux/OSX. 32-bit versions don't exist because it was added recently. If you're unsure of when your blockchain dates from, update it.

The attack works by flooding the network with low height (i.e. early) blocks. They would normally be added as alternates but if you're in the process of synching, they might get added as real blocks. This is because the checkpointing in the BCN code is not done well and it doesn't validate the headers of pre-checkpoint blocks. The number of people affected probably isn't that big but we can't have inconsistency in the network.

Because the attack is ongoing, if you resync from scratch you'll grab a few of these invalid blocks (about 1 in every ~500 blocks) so you'll still have a slightly corrupted chain. Update from the OP with the latest builds and chains and you'll be clean and protected. In the future, better checkpointing will be implemented but until then it won't be used.

Question: I did not update any of my miners with any of the new builds (e.g. with checkpointing) in the past day or two -- everything I have is from around May 4/5 I think. Does that mean my nodes are clean, or do I have to clear them all out, grab the latest version, and resync on all systems? My PC right now *thinks* it's mining, and it had at least through block 28000 or so prior to these attacks, so I should be safe, right? Will updating at this point benefit me or am I just asking for trouble? (It would be great to add a "version" command in the wallet and daemon -- provided of course that each new build remembers to update the version number.)

If you never had the checkpoint version and you synced everything yourself then your nodes are not affected by this issue.

Updating will give you a performance boost on mining. I can't think of any other changes that are really important.

[SlyWax]

Can you explain how someone could corrupt the block chain ?
If I'm synced with the network, then the checkpoint won't affect me since they are in the past.
And I won't accept changing old blocks.

So you should explain us how the checkpoint corrupted the blockchain, and how to check for a good or bad one.

Is'nt there a command to recheck the entire blockchain, without having to download it ?
If not, it is needed.

If you had a full chain, it very likely was never corrupted. (Of course there could always be bugs but we don't know of any that would do this.)

If you had tried to sync after the checkpoint was added, the code could have accepted some earlier blocks (before the checkpoint) without fully validating them.

If you downloaded a valid blockchain file (which would have included all of the blocks up to the checkpoint) and used the code version with the checkpoint, you were in all likelyhood not affected, other than some invalid blocks being accepted by your node (but offchain), bloating your memory and disk usage. This could have eventually become a denial-of-service issue, if the number of invalid blocks continued to grow.

There were probably very few people directly affected.

But when it comes to the integrity of the blockchain it does not pay to take chances. So the checkpoint has been temporarily removed forcing all blocks to be fully validated and will likely soon be added back in a safer way.

A command to validate the existing block chain is a good idea. We will look at that, possibly in connection with the improved checkpoint feature.

Thank you for the clarification.

How come an offchain block is stored on disk ?

[smooth]

Can you explain how someone could corrupt the block chain ?
If I'm synced with the network, then the checkpoint won't affect me since they are in the past.
And I won't accept changing old blocks.

So you should explain us how the checkpoint corrupted the blockchain, and how to check for a good or bad one.

Is'nt there a command to recheck the entire blockchain, without having to download it ?
If not, it is needed.

If you had a full chain, it very likely was never corrupted. (Of course there could always be bugs but we don't know of any that would do this.)

If you had tried to sync after the checkpoint was added, the code could have accepted some earlier blocks (before the checkpoint) without fully validating them.

If you downloaded a valid blockchain file (which would have included all of the blocks up to the checkpoint) and used the code version with the checkpoint, you were in all likelyhood not affected, other than some invalid blocks being accepted by your node (but offchain), bloating your memory and disk usage. This could have eventually become a denial-of-service issue, if the number of invalid blocks continued to grow.

There were probably very few people directly affected.

But when it comes to the integrity of the blockchain it does not pay to take chances. So the checkpoint has been temporarily removed forcing all blocks to be fully validated and will likely soon be added back in a safer way.

A command to validate the existing block chain is a good idea. We will look at that, possibly in connection with the improved checkpoint feature.

Thank you for the clarification.

How come an offchain block is stored on disk ?

I haven't looked at the disk writing code so I don't know what it stores. Given the issues with validation we can't be 100% sure the blocks didn't somehow make it into the chain. Everything is being validated now, so that can't possibly happen (we hope -- after all we are somewhat at the mercy of the bytecoin code until review it -- there is too much to just review everything).

[eizh]

Question: I did not update any of my miners with any of the new builds (e.g. with checkpointing) in the past day or two -- everything I have is from around May 4/5 I think. Does that mean my nodes are clean, or do I have to clear them all out, grab the latest version, and resync on all systems? My PC right now *thinks* it's mining, and it had at least through block 28000 or so prior to these attacks, so I should be safe, right? Will updating at this point benefit me or am I just asking for trouble? (It would be great to add a "version" command in the wallet and daemon -- provided of course that each new build remembers to update the version number.)

The first checkpoint was on May 3rd (see github). It could've started any time after that. So to clarify:

Let's say you started mining this coin on May 1st. You either synched your blockchain.bin from genesis or started from a download. Since then you never deleted that blockchain.bin even if you've updated your daemon/wallet builds (including the ones with checkpoints). In this case you're fine. If you've been mining this whole time without ever updating to the checkpoint versions, then you're also fine.

The other two cases are that you either started mining on/after May 3rd or you started mining before May 3rd but for some reason deleted your blockchain.bin to do a a fresh sync on/after May 3rd. In either of these cases, you need to update.