smooth



Offline



Activity: 2534

Merit: 1167









LegendaryActivity: 2534Merit: 1167 Re: [ANN][MRO] Monero - Anonymous Currency Based on Ring Signatures May 08, 2014, 09:28:54 PM #1143 Quote from: EFFV on May 08, 2014, 09:24:45 PM 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. 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.

AnonyMint



Offline



Activity: 518

Merit: 521







Hero MemberActivity: 518Merit: 521 Re: [ANN][MRO] Monero - Anonymous Currency Based on Ring Signatures May 08, 2014, 11:54:54 PM #1151



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. 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. unheresy.com - Prodigiously Elucidating the Profoundly Obtuse THIS FORUM ACCOUNT IS NO LONGER ACTIVE

SlyWax



Offline



Activity: 248

Merit: 251









Sr. MemberActivity: 248Merit: 251 Re: [ANN][MRO] Monero - Anonymous Currency Based on Ring Signatures May 09, 2014, 12:05:32 AM #1153 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



Offline



Activity: 2534

Merit: 1167









LegendaryActivity: 2534Merit: 1167 Re: [ANN][MRO] Monero - Anonymous Currency Based on Ring Signatures May 09, 2014, 12:16:14 AM #1154 Quote from: SlyWax on May 09, 2014, 12:05:32 AM 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. 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



Offline



Activity: 794

Merit: 1000





Monero (XMR) - secure, private, untraceable







Hero MemberActivity: 794Merit: 1000Monero (XMR) - secure, private, untraceable Re: [ANN][MRO] Monero - Anonymous Currency Based on Ring Signatures May 09, 2014, 12:22:58 AM #1155

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

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?

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_55set intel variables:for 3rd gen i7 i5 i3:for 2nd gen i7 i5 i3:for previous gen i7 i5 i3:for pentium-m (SSE3) intel processors:2) create the msvc project with cmake as specified in the op3) open the project in msvc and select Release instead of Debug4) right click on project external -> upnpc-static -> Intel Composer XE SP1 -> Intell C++. Same with those projects: comman, crypto, cryptonote_core, rpc, daemon5) 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 folder7) right click on daemon -> properties -> linker -> input -> additional dependencies and set those to:BuildIn 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).Tip me some MRO: 4AyRmUcxzefB5quumzK3HNE4zmCiGc8vhG6fE1oJpGVyVZF7fvDgSpt3MzgLfQ6Q1719xQhmfkM9Z2uNXgDMqYhjJVmc6KX About me | zRMicroArray - phase 2 - Gene Expression Analysis software | [Weed Like to Talk - Bulgaria] Start a wave of cannabis seminars in Europe | Monero weighted average price stats: moneroprice.i2p

BTC: 1KoCX7TWKVGwqmmFw3CKyUSrKRSStueZar | NMC: NKhYEYpe1Le9MwHrwKsdSm5617J4toVar9 | XMR (Tip me a beer OpenAlias Monero address): tip.changetheworldwork.com

[XMR] Monero - A secure, private, untraceable cryptocurrency: 4AyRmUcxzefB5quumzK3HNE4zmCiGc8vhG6fE1oJpGVyVZF7fvDgSpt3MzgLfQ6Q1719xQhmfkM9Z2u NXgDMqYhjJVmc6KX 1KoCX7TWKVGwqmmFw3CKyUSrKRSStueZar |NKhYEYpe1Le9MwHrwKsdSm5617J4toVar9 |tip.changetheworldwork.com4AyRmUcxzefB5quumzK3HNE4zmCiGc8vhG6fE1oJpGVyVZF7fvDgSpt3MzgLfQ6Q1719xQhmfkM9Z2uNXgDMqYhjJVmc6KX

eizh



Offline



Activity: 560

Merit: 500









Hero MemberActivity: 560Merit: 500 Re: [ANN][MRO] Monero - Anonymous Currency Based on Ring Signatures May 09, 2014, 12:33:10 AM #1157 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



Offline



Activity: 481

Merit: 500







Hero MemberActivity: 481Merit: 500 Re: [ANN][MRO] Monero - Anonymous Currency Based on Ring Signatures May 09, 2014, 12:47:43 AM #1158 Quote from: eizh on May 09, 2014, 12:33:10 AM 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.) 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.) Subscribe to my cryptocurrency newsletter

smooth



Offline



Activity: 2534

Merit: 1167









LegendaryActivity: 2534Merit: 1167 Re: [ANN][MRO] Monero - Anonymous Currency Based on Ring Signatures May 09, 2014, 12:54:48 AM #1159 Quote from: trogdorjw73 on May 09, 2014, 12:47:43 AM Quote from: eizh on May 09, 2014, 12:33:10 AM 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.)

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.





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.