cryptonit
Legendary
Offline
Activity: 3052
Merit: 1053
bit.diamonds | uNiq.diamonds
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 11, 2014, 09:02:39 AM |
|
DMD Cloudmining investment update: now at 11th november already more new investments created than in whole october lot of them are investments of people who already own shares hmmm why this happens? might be they discovered it works and it works good? ![](https://ip.bitcointalk.org/?u=http%3A%2F%2Fi60.tinypic.com%2Ft5m7ps.png&t=665&c=4JFCnK4lyVrBoQ)
|
|
|
|
danbi
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 11, 2014, 09:56:24 AM |
|
please update the algo to make ASIC and FPGA devices unable to operate on DMD.
sooner the better please.
This is being discussed now, and should be valuable to discuss here as well. The main issue with algorithm switch is it will again return everyone in square 1. Our switch to Groestl demonstrated that miner software authors are sometimes hesitant to implement new code (sometimes not). If we decide to switch the algorithm again (not a problem, for the wallet/blockchain as we know now), we need to be prepared for that as well. Oh, and the pools need to figure out how to support the new algorithms ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) The other, much more difficult question is what would that other algorithm be? This question is hard, because good crypto algorithms are also developed to be cheap to implement. Which makes them very good candidates for ASIC/FPGA type acceleration. About the only way to make it more CPU/GPU friendly is to require addressing large amounts of memory -- which makes it way more expensive to do in a cheap ASIC/FPGA, but also sometimes favors specific GPU architecture.
|
BTC: 15cJkRupKAkGr6sTxj1Uzb6uHbvuRyK1GL DMD: dJZEqNcjiUiMMd8DKBFS9oMWtArAD2GCHr
|
|
|
pallas
Legendary
Offline
Activity: 2716
Merit: 1094
Black Belt Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 11, 2014, 10:03:02 AM |
|
please update the algo to make ASIC and FPGA devices unable to operate on DMD.
sooner the better please.
This is being discussed now, and should be valuable to discuss here as well. The main issue with algorithm switch is it will again return everyone in square 1. Our switch to Groestl demonstrated that miner software authors are sometimes hesitant to implement new code (sometimes not). If we decide to switch the algorithm again (not a problem, for the wallet/blockchain as we know now), we need to be prepared for that as well. Oh, and the pools need to figure out how to support the new algorithms ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) The other, much more difficult question is what would that other algorithm be? This question is hard, because good crypto algorithms are also developed to be cheap to implement. Which makes them very good candidates for ASIC/FPGA type acceleration. About the only way to make it more CPU/GPU friendly is to require addressing large amounts of memory -- which makes it way more expensive to do in a cheap ASIC/FPGA, but also sometimes favors specific GPU architecture. as far as I know, the only interesting algorythm is cryptonight which uses 2MB of cache for each computing unit, making it well suited for current generation cpus. still, gpu miners exist and are almost as efficient, until someone figures out how to make them better and cpus will be out of the equation again. such a niche algorythm could well have some flaws which, if discovered by a large fpga farm or asic maker, will make it useless.
|
|
|
|
danbi
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 11, 2014, 10:14:43 AM |
|
All,
I am/was mining at 138 mh/s while all of this went down and it appeared to me that the issue was in 3 waves based on what I saw with the difficulty. It was hovering around 130 yesterday and then plummeted to 19 or so. I went to coinwarz to check their stats and the site validated what I was seeing. At that point, it was a head-scratching moment but I thought that a pool went offline, such as what many are suggesting. It stayed around 20 for about 20 minutes and then started to creep up again until it went to 100 again. Then it went down again to 4. It went back up to perhaps 40 or so and them went to 0, all the while I was mining. I checked/refreshed coinwarz again and it validated the 0 difficulty again. Last night I checked coinwarz and cryptsy again and it was showing 130 difficulty, even though I was seeing difficulty at 3. My rig is still connected and mining, basically because if there was an issue and I ended up being the only miner on the network, I wanted the advantage. And, even though I have not lost connectivity to the minter, I appear to be on the fork versus the correct chain. Let me know what I can do to get any info to the group. I used to be a follower/miner of the coin and lost interest for a while and decided to give it another try after finding I can have a high hash rate with the new algorithm. As of yesterday, when I checked the network hash rate of the "new" difficulty, it showed around 300 mh/s with me using 138 or so. Perhaps another miner on the same chain? But why would I not have been on the "real" blockchain all along if I never stopped mining and continued to solve blocks? Anyway, let me know what I can do to help shed light on the situation.
Short summary: when you find yourself in a hole, stop digging! :-) A bit longish: You can newer 'win' over the Diamond's "official" chain. No matter how ahead you are, chain length wise. This is because Diamond has many features that prevent such from happening -- in the long term. Short term 'wins' are possible, but it's random game. When you find yourself on the wrong chain with diamond, and you are actively mining, there are two things you can do to minimize your loss: 1. Stop mining! When the 'official' block chain grows over your fork, you can rejoin and start mining again. 2. Re-download the chain and start mining again. You could save copies of your own blockchain to make this faster (everything except wallet.dat). Or use any of the "official" backups, or just download it from the start again (worst idea). If you use someone else's backup, no matter how 'official' it is, it is always advisable to do validation of it with the wallet, as it might be tampered with in some way -- use the -checkblock=0 -checklevel=6 parameters when starting the wallet -- this will take long time, but you will know at least the things the wallet checks for are correct. In mean time, while you wait for 1. or 2. to complete, you can always mine at the Diamond multipool ( http://multippol.bit.diamonds) to not have your miners idle. The above advice has been repeated a number of times here, as well as advice on how to configure your nodes (miner, or not) to reduce the chance of such situation happening again. Check the first post as well.
|
BTC: 15cJkRupKAkGr6sTxj1Uzb6uHbvuRyK1GL DMD: dJZEqNcjiUiMMd8DKBFS9oMWtArAD2GCHr
|
|
|
LTCMAXMYR
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 11, 2014, 10:28:18 AM |
|
please update the algo to make ASIC and FPGA devices unable to operate on DMD.
sooner the better please.
This is being discussed now, and should be valuable to discuss here as well. The main issue with algorithm switch is it will again return everyone in square 1. Our switch to Groestl demonstrated that miner software authors are sometimes hesitant to implement new code (sometimes not). If we decide to switch the algorithm again (not a problem, for the wallet/blockchain as we know now), we need to be prepared for that as well. Oh, and the pools need to figure out how to support the new algorithms ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) The other, much more difficult question is what would that other algorithm be? This question is hard, because good crypto algorithms are also developed to be cheap to implement. Which makes them very good candidates for ASIC/FPGA type acceleration. About the only way to make it more CPU/GPU friendly is to require addressing large amounts of memory -- which makes it way more expensive to do in a cheap ASIC/FPGA, but also sometimes favors specific GPU architecture. as far as I know, the only interesting algorythm is cryptonight which uses 2MB of cache for each computing unit, making it well suited for current generation cpus. still, gpu miners exist and are almost as efficient, until someone figures out how to make them better and cpus will be out of the equation again. such a niche algorythm could well have some flaws which, if discovered by a large fpga farm or asic maker, will make it useless. cryptonight is not FPGA resistance,even XPM is not FPGA resistance, the only FPGA resistance and GPU friendly algo is hefty
|
Never buy any ICO altcoin. Never buy any ASIC altcoin.
|
|
|
pallas
Legendary
Offline
Activity: 2716
Merit: 1094
Black Belt Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 11, 2014, 10:36:57 AM |
|
This is being discussed now, and should be valuable to discuss here as well. The main issue with algorithm switch is it will again return everyone in square 1. Our switch to Groestl demonstrated that miner software authors are sometimes hesitant to implement new code (sometimes not). If we decide to switch the algorithm again (not a problem, for the wallet/blockchain as we know now), we need to be prepared for that as well. Oh, and the pools need to figure out how to support the new algorithms ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) The other, much more difficult question is what would that other algorithm be? This question is hard, because good crypto algorithms are also developed to be cheap to implement. Which makes them very good candidates for ASIC/FPGA type acceleration. About the only way to make it more CPU/GPU friendly is to require addressing large amounts of memory -- which makes it way more expensive to do in a cheap ASIC/FPGA, but also sometimes favors specific GPU architecture. as far as I know, the only interesting algorythm is cryptonight which uses 2MB of cache for each computing unit, making it well suited for current generation cpus. still, gpu miners exist and are almost as efficient, until someone figures out how to make them better and cpus will be out of the equation again. such a niche algorythm could well have some flaws which, if discovered by a large fpga farm or asic maker, will make it useless. cryptonight is not FPGA resistance,even XPM is not FPGA resistance, the only FPGA resistance and GPU friendly algo is hefty could you please point me to hefty specifications and/or discussion on this supposed FPGA resistance? can't seem to find any whitepaper or algorithm description.
|
|
|
|
cryptonit
Legendary
Offline
Activity: 3052
Merit: 1053
bit.diamonds | uNiq.diamonds
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 11, 2014, 10:40:51 AM |
|
as far as I know, the only interesting algorythm is cryptonight which uses 2MB of cache for each computing unit, making it well suited for current generation cpus. still, gpu miners exist and are almost as efficient, until someone figures out how to make them better and cpus will be out of the equation again. such a niche algorythm could well have some flaws which, if discovered by a large fpga farm or asic maker, will make it useless.
CryptoNight also have lot coins using it so profitswitching multipools are existing so avoid fpga and asics and run into arms of multipools is that a win? in my opinion a specialized algo no one else run at the moment (best multipool prevention) as base of the DMD Diamond merged mining family would be the only other option to just stick with groestl but even we have lot skill in team create a own algo isnt one of it and a algo is such a important part of network we dont wana make experiments maybe we have some cryptographic expert in our community who have the skill to modify example CryptoNight into a "CryptoBright" algo which would be DMD Diamonds new algo if ya know people with such a skillset let them get in touch with us and explore possibilities
|
|
|
|
pallas
Legendary
Offline
Activity: 2716
Merit: 1094
Black Belt Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 11, 2014, 10:49:39 AM |
|
I belive we should stick with a well known and documented algo, with academic background, like groestl. IMHO, cryptography is not a thing you can make in-house.
|
|
|
|
LTCMAXMYR
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 11, 2014, 10:51:27 AM |
|
This is being discussed now, and should be valuable to discuss here as well. The main issue with algorithm switch is it will again return everyone in square 1. Our switch to Groestl demonstrated that miner software authors are sometimes hesitant to implement new code (sometimes not). If we decide to switch the algorithm again (not a problem, for the wallet/blockchain as we know now), we need to be prepared for that as well. Oh, and the pools need to figure out how to support the new algorithms ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) The other, much more difficult question is what would that other algorithm be? This question is hard, because good crypto algorithms are also developed to be cheap to implement. Which makes them very good candidates for ASIC/FPGA type acceleration. About the only way to make it more CPU/GPU friendly is to require addressing large amounts of memory -- which makes it way more expensive to do in a cheap ASIC/FPGA, but also sometimes favors specific GPU architecture. as far as I know, the only interesting algorythm is cryptonight which uses 2MB of cache for each computing unit, making it well suited for current generation cpus. still, gpu miners exist and are almost as efficient, until someone figures out how to make them better and cpus will be out of the equation again. such a niche algorythm could well have some flaws which, if discovered by a large fpga farm or asic maker, will make it useless. cryptonight is not FPGA resistance,even XPM is not FPGA resistance, the only FPGA resistance and GPU friendly algo is hefty could you please point me to hefty specifications and/or discussion on this supposed FPGA resistance? can't seem to find any whitepaper or algorithm description. FPGA experts proved,almost every algos are made FPGA in the world, i know some truth you may never see or out of imagine,change algos only means change the battle field, destroy a coin,is not the FPGA,nor ASIC true GPU cannot rescue a coin
|
Never buy any ICO altcoin. Never buy any ASIC altcoin.
|
|
|
cryptonit
Legendary
Offline
Activity: 3052
Merit: 1053
bit.diamonds | uNiq.diamonds
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 11, 2014, 10:51:40 AM |
|
cryptonight is not FPGA resistance,even XPM is not FPGA resistance, the only FPGA resistance and GPU friendly algo is hefty
how it comes HEFTY1 is in ur opinion more asic resistant than cryptonight? sounds just like another algo mix similar to x11 Introduces HEFTY1, a novel approach to ASIC-resistant proof-of-work Ultra-secure: combines SHA-256, Keccak-512, Grøestl-512, BLAKE-512 in a secure way in my opinion the cryptonight claim that high ram requirement make profitable asics/fpga unprofitable (at least the next few technology generations) sounds very reasonable
|
|
|
|
LTCMAXMYR
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 11, 2014, 12:05:03 PM |
|
cryptonight is not FPGA resistance,even XPM is not FPGA resistance, the only FPGA resistance and GPU friendly algo is hefty
how it comes HEFTY1 is in ur opinion more asic resistant than cryptonight? sounds just like another algo mix similar to x11 Introduces HEFTY1, a novel approach to ASIC-resistant proof-of-work Ultra-secure: combines SHA-256, Keccak-512, Grøestl-512, BLAKE-512 in a secure way in my opinion the cryptonight claim that high ram requirement make profitable asics/fpga unprofitable (at least the next few technology generations) sounds very reasonable most new algos,FPGA is made before public a GPU software, in the beginning,a few FPGA borads fight against hundreds of thousands of CPUs, do you even think the hashpower was the botnet? few days later, GPU public,everybody join in,and FPGA disappear, so you never see public FPGA miner, FPGA exist In the legend,only few people saw it. qurak,qubit,skein,blake,scrypt-series,X-series,hefty,prime-series, cryptonight ,,,,all have FPGA miner. FPGA killed darkcoin?no DMD,is groestl algo,and groestlcoin,have FPGA miner?of course,the FPGA miner exist before the coin birthday.maybe ASIC had been prepared. HEFTY1 algo is proved,FPGA cannot fight against GPU,but these series coins are almost dead. true FPGA&ASIC resistance and GPU friendly coin is killed by GPU,it is really a joke.
|
Never buy any ICO altcoin. Never buy any ASIC altcoin.
|
|
|
pallas
Legendary
Offline
Activity: 2716
Merit: 1094
Black Belt Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 11, 2014, 12:15:24 PM |
|
most new algos,FPGA is made before public a GPU software, FPGA exist In the legend,only few people saw it.
So I guess you are one of those, otherwise how could you know for sure? Would you share some fpga code, then? HEFTY1 algo is proved,FPGA cannot fight against GPU
Show me the proof :-) Till now I only see blah blah blah
|
|
|
|
LTCMAXMYR
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 11, 2014, 12:27:09 PM |
|
most new algos,FPGA is made before public a GPU software, FPGA exist In the legend,only few people saw it.
So I guess you are one of those, otherwise how could you know for sure? Would you share some fpga code, then? HEFTY1 algo is proved,FPGA cannot fight against GPU
Show me the proof :-) Till now I only see blah blah blah you should visit this website,and look around some team works, http://cryptography.gmu.edu/athena/index.php?id=source_codesi just told the truth,and don't care if people believe it or not.
|
Never buy any ICO altcoin. Never buy any ASIC altcoin.
|
|
|
pallas
Legendary
Offline
Activity: 2716
Merit: 1094
Black Belt Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 11, 2014, 12:35:16 PM |
|
most new algos,FPGA is made before public a GPU software, FPGA exist In the legend,only few people saw it.
So I guess you are one of those, otherwise how could you know for sure? Would you share some fpga code, then? HEFTY1 algo is proved,FPGA cannot fight against GPU
Show me the proof :-) Till now I only see blah blah blah you should visit this website,and look around some team works, http://cryptography.gmu.edu/athena/index.php?id=source_codesi just told the truth,and don't care if people believe it or not. that is just generic code for the generic hashing functions; there is no coin implementation. nor any proof that it is more power efficient than gpu. if you show me that link, I'll show you one where they say there is asic for groestl: http://www.groestl.info/implementations.htmlbut that doesn't mean there is an asic miner for diamond.
|
|
|
|
Mister1k
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 11, 2014, 12:46:14 PM |
|
can someone confirm his wallet did reorg back into the correct chain without any action needed
this should be the normal behavior in case u where some time on wrong chain
we still analyzing what happend normal the selfhealing abilities of wallet should be able overcome a fork situation and reorg u back into mainchain without interaction required
(dont make the word fork scare u every mined orphan create a fork but it normal only lasts one block that wallet reorg back to main blockchain)
I don't think that happened. Normally one block to reorganise. No. That never happened. He had to intervene. Just seems ironic that miningfield opens a US pool and basically less than a week later It is attacked and forks the chain. The diff is still off the map. 50 points change in the span of one or two blocks. Yesterday I watched the hash rate go from 12 ghs to 6 ghs in less than a minute. At one time Danbi pool hash was greater than the net hash..diff 90 and then 220. It almost like someone throws a switch and the diff/hash rate goes berserk. When I realized I was forked on Us miningfield. I checked my wallet and it was absolutely perfect. Connect= (I never use add node or listen=1) since the july 31 attack. listen=0 I would like to know how many were affected.. There was only 5 workers on that pool,2 of which were mine. As a check for acurracy. I started solo on one machine and danbi pool on another using wallet as standard to check. They were absolutely synced,correct block,correct diff. Its also ironic that someone had a pool going,got pissed off,it disappears. A new pool is created to replace. And it is attacked.. For 5 workers. Hmmm.. Not mentioning names. Food for thought. This was a localized attack.IMHO
|
|
|
|
LTCMAXMYR
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 11, 2014, 12:57:37 PM |
|
can someone confirm his wallet did reorg back into the correct chain without any action needed
this should be the normal behavior in case u where some time on wrong chain
we still analyzing what happend normal the selfhealing abilities of wallet should be able overcome a fork situation and reorg u back into mainchain without interaction required
(dont make the word fork scare u every mined orphan create a fork but it normal only lasts one block that wallet reorg back to main blockchain)
I don't think that happened. Normally one block to reorganise. No. That never happened. He had to intervene. Just seems ironic that miningfield opens a US pool and basically less than a week later It is attacked and forks the chain. The diff is still off the map. 50 points change in the span of one or two blocks. Yesterday I watched the hash rate go from 12 ghs to 6 ghs in less than a minute. At one time Danbi pool hash was greater than the net hash..diff 90 and then 220. It almost like someone throws a switch and the diff/hash rate goes berserk. When I realized I was forked on Us miningfield. I checked my wallet and it was absolutely perfect. Connect= (I never use add node or listen=1) since the july 31 attack. listen=0 I would like to know how many were affected.. There was only 5 workers on that pool,2 of which were mine. As a check for acurracy. I started solo on one machine and danbi pool on another using wallet as standard to check. They were absolutely synced,correct block,correct diff. Its also ironic that someone had a pool going,got pissed off,it disappears. A new pool is created to replace. And it is attacked.. For 5 workers. Hmmm.. Not mentioning names. Food for thought. This was a localized attack.IMHO a few days ago,i saw 35Gh net hashrate. i mint on miningfield 2 weeks ago,because of net lack,i solo minng,use 3Gh . luckily, it is on the main chain. i don't know why the connection is so few,only 2 connections all the time.
|
Never buy any ICO altcoin. Never buy any ASIC altcoin.
|
|
|
cryptonit
Legendary
Offline
Activity: 3052
Merit: 1053
bit.diamonds | uNiq.diamonds
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 11, 2014, 01:06:01 PM |
|
This was a localized attack.IMHO
my main minting wallet was on the fork too i didnt mine at that pool it was not local only connected to us.miningfield west US backbone node and my minting wallet where affected too when i was in fork i had never above 5 connections so it was most likely just a handful wallets affected ur between the line guess about attack origin i strong disbelieve there would be required skills to try such thing reorg can work backwards far more than one block as i said before i tested once with over 600 blocks which did reorg back to mainchain
|
|
|
|
Mister1k
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 11, 2014, 02:02:34 PM |
|
This was a localized attack.IMHO
my main minting wallet was on the fork too i didnt mine at that pool it was not local only connected to us.miningfield west US backbone node and my minting wallet where affected too when i was in fork i had never above 5 connections so it was most likely just a handful wallets affected ur between the line guess about attack origin i strong disbelieve there would be required skills to try such thing reorg can work backwards far more than one block as i said before i tested once with over 600 blocks which did reorg back to mainchain That is what i mean a local attack on Us. Miningfield. And he had to intervene correct? Yes! So reorganize didn't work.Did he have to redownload the correct block chain? I believe so,but he could answer that. And I'll spell it out for you,quote: ur between the line quess origin i strong disbelieve there would require skills to try such a thing. Well I strongly believe you pissed off one Utah John who has the skills.who was implementing a Us pool, that got the axe. A new replacement us .minigfield was implemented. Funny this was pool that was attacked. In less than week. If your minting wallet was affected and you weren't mining that pool You have got some serious issues. My miners were forked my wallet was not. I was minting aswell. Absolutely flawless. No problems with the wallet. So I ask you how was your wallet attacked because it was? The chain was forked for at least 6 hours and that is how many self healing blocks? Yah There is a saying in this country. The toe you step on today might be the ass you kiss tomorrow..
|
|
|
|
pallas
Legendary
Offline
Activity: 2716
Merit: 1094
Black Belt Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 11, 2014, 02:15:48 PM |
|
I think I can speak for the community: we won't be kissing any ass ;-)
|
|
|
|
cryptonit
Legendary
Offline
Activity: 3052
Merit: 1053
bit.diamonds | uNiq.diamonds
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 11, 2014, 02:17:52 PM Last edit: November 11, 2014, 02:31:41 PM by cryptonit |
|
I think I can speak for the community: we won't be kissing any ass ;-)
![Grin](https://bitcointalk.org/Smileys/default/grin.gif) ![](https://ip.bitcointalk.org/?u=http%3A%2F%2Fnaqyr37xcg93tizq734pqsx1.wpengine.netdna-cdn.com%2Fwp-content%2Fuploads%2F2013%2F03%2FKick-Ass-Picture-Quote.jpg&t=665&c=CqLlnxTAZdE54w)
|
|
|
|
|