Author

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

legendary
Activity: 2968
Merit: 1198
Someone (C++ skilled) did private optimized miner a few days ago, he got 74H/s for i5 haswell. He pointed that mining code was very unoptimized and he did essential improvements for yourself. So, high H/S is possible yet.
Can the dev's core review code for that?

Let me explain a bit about how open source works. Anyone is free to contribute. The lead developer and core team reviews the proposed changes and either adopts them or not. There is at least one of the core team who does work on optimization, and posted some optimizations. I would not be surprised if he develops further optimizations as well.

So if you have proposed code changes, please submit them. Some sort of statement -- backed up by zero evidence -- about a unicorn miner that someone has is not helpful. Every altcoin has these "Kaiser Soze" miners who supposedly have much faster mining code than everybody else. Sometimes it's true and sometimes it isn't. We can't force anyone to contribute their code.



legendary
Activity: 2968
Merit: 1198
wondering if the reason I have not gotten any blocks in the last week is because I have been mining on a corrupted blockchain.

How much hash rate do you have?

Unlikely that the block chain is the issue, as long as you are synced properly. Any problems with the block chain would be with very old blocks (near genesis). Could affect old coin balances but would not affect current mining.

member
Activity: 80
Merit: 10
wondering if the reason I have not gotten any blocks in the last week is because I have been mining on a corrupted blockchain.
legendary
Activity: 1151
Merit: 1003
Someone (C++ skilled) did private optimized miner a few days ago, he got 74H/s for i5 haswell. He pointed that mining code was very unoptimized and he did essential improvements for yourself. So, high H/S is possible yet.
Can the dev's core review code for that?
hero member
Activity: 560
Merit: 500
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.
legendary
Activity: 2968
Merit: 1198
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).

sr. member
Activity: 248
Merit: 251
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 ?
legendary
Activity: 2968
Merit: 1198
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.


hero member
Activity: 482
Merit: 500
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.)
hero member
Activity: 560
Merit: 500
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.
legendary
Activity: 2968
Merit: 1198

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.

hero member
Activity: 794
Merit: 1000
Monero (XMR) - secure, private, untraceable
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
Cool 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 Sad so they can’t be used.
Tip me some MRO: 4AyRmUcxzefB5quumzK3HNE4zmCiGc8vhG6fE1oJpGVyVZF7fvDgSpt3MzgLfQ6Q1719xQhmfkM9Z2u NXgDMqYhjJVmc6KX
Also I want to buy 0.02623544 BTC worth of MRO. Someone?
legendary
Activity: 2968
Merit: 1198
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.
sr. member
Activity: 248
Merit: 251
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.
full member
Activity: 153
Merit: 107
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.
hero member
Activity: 518
Merit: 521
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.
member
Activity: 196
Merit: 10
HOPE you don't fork over weekend. I am out of town.
legendary
Activity: 2968
Merit: 1198
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.
legendary
Activity: 2156
Merit: 1131
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.
hero member
Activity: 560
Merit: 500
Windows binaries have been uploaded. Everything in the OP now has the security fix. I'll upload blockchains soon (check for May 8th date).
Jump to: