Author

Topic: ★★DigiByte|极特币★★[DGB]✔ Core v6.16.5.1 - DigiShield, DigiSpeed, Segwit - page 1173. (Read 3058816 times)

full member
Activity: 146
Merit: 100
On Cryptsy  a few million DGB was sold at 16 sat within the past 2 hours or so.  Roughly .8 BTC worth if I had to guess
hero member
Activity: 924
Merit: 1000
Where do you see that?

YC

The sell pressure has just increased at 16 SAT. Time to buy more.
full member
Activity: 204
Merit: 100
Algo Hashrate Equivalents

(With configurations tweaked so that a target temperature of 80º is respected and not repeatedly hit (where the cards settle into a 78º +-1º temp and work nicely with fan speeds that average 50% when using groestl, but run much hotter and faster, respectively, using the other algos).

SHA-256 = 1 GH/s  
Scrypt = 1 MH/s  
Groestl = 40 MH/s  
Skein = 120 MH/s  
Qubit = 5.65 MH/s  

Does anyone have differing stats?

@Arsenay, yesterday I pulled down 55,827 with only four 7950's - and I've averaged 57,953 over the last 4 days (with cool running, energy efficient, -k myriadcoin-groestl).  Smiley




I have not above 66 degrees
operating temperature of 7950 and 7970 in the case
and 60 degrees for 7790
and 7790 in general can work with a shutdown cooler
only by blowing casing.
once again:
I did not have the goal to create a heat gun of video cards
and endlessly tinkering with drivers
and squeeze out "water stones"

I engaged in the development of military equipment
and know the price of overheating and is familiar with the calculation of reliability
so ...))
legendary
Activity: 1106
Merit: 1000
The future is bright with DigiByte.
The sell pressure has just increased at 16 SAT. Time to buy more.
full member
Activity: 146
Merit: 100
HR, which driver are you using for your cards? I think my 280x might have to go back to 13.12 for the optimized kernel....from what im reading anyway.  From my understanding, Groestl favors more of the older generation of cards and the newer gen cards need some tweaking to compete.
legendary
Activity: 1106
Merit: 1000
The future is bright with DigiByte.
Hello Jared and community,

I hope this attack will never take place... as long as hash rate is high, the probability is quite low... but still possible...
Imagine if it was combined with %51 attack, then he can quickly mine at a very low difficulty to gather a lot of coins in a short while.

I think this fix should be the priority.  And this is not only for DGB, every coin using 1 block retargeting should consider this, especially those who are still on KGW.

Ref 1. https://litecoin.info/Time_warp_attack (Also check the second REF for eliminating the attack on litecoin )
Ref 2. https://bitcointalksearch.org/topic/m.6016831
Ref 3. https://bitcointalksearch.org/topic/m.6746665 (Also skim the whole page)

And finally Myriad made their fixes. Should talk to them and get this done ASAP.
Ref 4. http://www.cryptoarticles.com/crypto-news/mandatory-myriadcoin-upgrade-includes-stealth-addresses-new-weighting-algo-more

I know in bitcoin, it is impossible to take advantage of this crack since there is always created blocks in a quite fast manner.
However, those coins who have this problem in common are using the same bitcoin source.

Cheers.

My reading of things is that the further away you get from the original specs and coding, the wider you're opening Pandora's Box. I found this thread to be very instructive: https://bitcointalksearch.org/topic/bug-time-warp-exploits-why-is-the-attack-chain-accepted-608893



Yep, that is the third REF in my post. That is quite helpful.
HR
legendary
Activity: 1176
Merit: 1011
Transparency & Integrity
Hello Jared and community,

I hope this attack will never take place... as long as hash rate is high, the probability is quite low... but still possible...
Imagine if it was combined with %51 attack, then he can quickly mine at a very low difficulty to gather a lot of coins in a short while.

I think this fix should be the priority.  And this is not only for DGB, every coin using 1 block retargeting should consider this, especially those who are still on KGW.

Ref 1. https://litecoin.info/Time_warp_attack (Also check the second REF for eliminating the attack on litecoin )
Ref 2. https://bitcointalksearch.org/topic/m.6016831
Ref 3. https://bitcointalksearch.org/topic/m.6746665 (Also skim the whole page)

And finally Myriad made their fixes. Should talk to them and get this done ASAP.
Ref 4. http://www.cryptoarticles.com/crypto-news/mandatory-myriadcoin-upgrade-includes-stealth-addresses-new-weighting-algo-more

I know in bitcoin, it is impossible to take advantage of this crack since there is always created blocks in a quite fast manner.
However, those coins who have this problem in common are using the same bitcoin source.

Cheers.

My reading of things is that the further away you get from the original specs and coding, the wider you're opening Pandora's Box. I found this thread to be very instructive: https://bitcointalksearch.org/topic/bug-time-warp-exploits-why-is-the-attack-chain-accepted-608893

Edit:

I like the idea of forced block discovery rotation between algos (so that no one algo can find multiple blocks in a row), but the idea that somehow the various difficulties did not already have a shared, combined weighting is not correct - they did, and as one algo's diff rose, so did the others in exact same proportions.

Keep It Simple Stupid: if it ain't broke, don't fix it, and only fix what absolutely needs to be fixed - otherwise we'll end up somewhere down the road with a collection of uncommented, undecipherable, ad hoc coding that nobody understands.

What I'm saying is BE CAREFUL, very careful, and especially so when collaborating with people who may or may not know what they're doing.

full member
Activity: 146
Merit: 100
Algo Hashrate Equivalents

(With configurations tweaked so that a target temperature of 80º is respected and not repeatedly hit (where the cards settle into a 78º +-1º temp and work nicely with fan speeds that average 50% when using groestl, but run much hotter and faster, respectively, using the other algos).

SHA-256 = 1 GH/s  
Scrypt = 1 MH/s  
Groestl = 40 MH/s  
Skein = 120 MH/s  
Qubit = 5.65 MH/s  

Does anyone have differing stats?

@Arsenay, yesterday I pulled down 55,827 with only four 7950's - and I've averaged 57,953 over the last 4 days (with cool running, energy efficient, -k myriadcoin-groestl).  Smiley



HR, thanks for your analysis on the cards and server locations.  I need to get switched over.  I only brought in 70,000 with both my rigs yesterday which are a mix of 270x / 280x.  Either way, I am convinced that I could be bringing in more with the optimized groestl kernels.  From what I read I should be getting around 15 mh on my 280x's but I undervolt a ton so I probably wont be able to get that much. 

For the server locations I just did a nslookup on digihash.co so I must have been bumped to the NJ location.

Thanks again.
-Kayahoga
hero member
Activity: 924
Merit: 1000
It may be wise to not send or receive any coins until the fix has been put in place.

YC

Hello Jared and community,

I hope this attack will never take place... as long as hash rate is high, the probability is quite low... but still possible...
Imagine if it was combined with %51 attack, then he can quickly mine at a very low difficulty to gather a lot of coins in a short while.

I think this fix should be the priority.  And this is not only for DGB, every coin using 1 block retargeting should consider this, especially those who are still on KGW.

Ref 1. https://litecoin.info/Time_warp_attack (Also check the second REF for eliminating the attack on litecoin )
Ref 2. https://bitcointalksearch.org/topic/m.6016831
Ref 3. https://bitcointalksearch.org/topic/m.6746665 (Also skim the whole page)

And finally Myriad made their fixes. Should talk to them and get this done ASAP.
Ref 4. http://www.cryptoarticles.com/crypto-news/mandatory-myriadcoin-upgrade-includes-stealth-addresses-new-weighting-algo-more

I know in bitcoin, it is impossible to take advantage of this crack since there is always created blocks in a quite fast manner.
However, those coins who have this problem in common are using the same bitcoin source.

Cheers.
HR
legendary
Activity: 1176
Merit: 1011
Transparency & Integrity
Can anyone confirm that Digihash is hosted in New Jersey? I thought it was going to be in Texas or something originally but since my ping time is a lot lower than when it first went live I am going to switch over.  Plus, supporting the devs =).  

Also a thumbs up for http://birdspool.no-ip.org:5021/static/stats/ that p2pool has been rock solid and birds a cool guy that I've gotten a chance to talk to a few times.  If you are really concerned about your fees, I believe birdspool is only .5% if im not mistaken.


Its my opinion we really should be spreading the hash around by supporting the Devs pool or boosting the P2pool pools.

The IP for DigiHash is 66.228.56.115 and that points to Atlanta, Georgia, but the router at linode.com looks like it can re-route on demand to Absecon, New Jersey (both East Coast locations and ideal for anyone on that side of the U.S., and even for folks on the West Coast it's still one of the best bets). Bird's P2Pool is located in Massachusetts, CryptoMiningPool is now located in England, The Blocks Factory and Miners Pool EU are both French based, and that's the rundown for the Groestl pools' server locations.

For the rest of the pools that don't also offer Groestl mining, OmarG Pool's server is located in Niagara Falls, Ontario, Canada, ispace is located in New Jersery (in spite of its co.uk top level domain), CoinMine is in Phoenix, Arizona, DigiForce is located in Bayern, Germany, E-Pool is in Netherlands, and French P2P is also French as its name suggests.

Good coverage for North American and European miners, but with a noticeable gap in Asian coverage (not even Australia or New Zealand, surprisingly). I wonder about private pools in Asia . . . and attackers . . . the more transparency the better . . . all pools should be obligated to publish their name in the blockchain with each block found (and solo miners with an IP identification at least), and there should also be more security layers added with e-mail registration for each new wallet install, etc., but those are other issues that I've harped on before, and will leave for, other, future occasions. Wink
legendary
Activity: 1106
Merit: 1000
The future is bright with DigiByte.
Hello Jared and community,

I hope this attack will never take place... as long as hash rate is high, the probability is quite low... but still possible...
Imagine if it was combined with %51 attack, then he can quickly mine at a very low difficulty to gather a lot of coins in a short while.

I think this fix should be the priority.  And this is not only for DGB, every coin using 1 block retargeting should consider this, especially those who are still on KGW.

Ref 1. https://litecoin.info/Time_warp_attack (Also check the second REF for eliminating the attack on litecoin )
Ref 2. https://bitcointalksearch.org/topic/m.6016831
Ref 3. https://bitcointalksearch.org/topic/m.6746665 (Also skim the whole page)

And finally Myriad made their fixes. Should talk to them and get this done ASAP.
Ref 4. http://www.cryptoarticles.com/crypto-news/mandatory-myriadcoin-upgrade-includes-stealth-addresses-new-weighting-algo-more

I know in bitcoin, it is impossible to take advantage of this crack since there is always created blocks in a quite fast manner.
However, those coins who have this problem in common are using the same bitcoin source.

Cheers.
hero member
Activity: 756
Merit: 500
Community Liaison,How can i help you?
You guys are tech maniacs in my eyes, allot of information coming in and i can´t keep up!

Lovin it!
http://www.youtube.com/watch?v=I6zA6g4MAcE
HR
legendary
Activity: 1176
Merit: 1011
Transparency & Integrity
Algo Hashrate Equivalents

(With configurations tweaked so that a target temperature of 80º is respected and not repeatedly hit (where the cards settle into a 78º +-1º temp and work nicely with fan speeds that average 50% when using groestl, but run much hotter and faster, respectively, using the other algos).

SHA-256 = 1 GH/s  
Scrypt = 1 MH/s  
Groestl = 40 MH/s  
Skein = 120 MH/s  
Qubit = 5.65 MH/s  

Does anyone have differing stats?

@Arsenay, yesterday I pulled down 55,827 with only four 7950's - and I've averaged 57,953 over the last 4 days (with cool running, energy efficient, -k myriadcoin-groestl).  Smiley

legendary
Activity: 1722
Merit: 1051
Official DigiByte Account
Since our difficulty adjustment is different than Myriad we have some more protection for this.

I don't see how that follows.  It's really the exact same thing but with max adjustments increased 10x.  Historically this has led to insane difficulty swings (even at constant hashrates) which can be difficult to distinguish from actual tomfoolery without going in and comparing timestamps. One slight advantage is that -log(max_diff_down)/log(min_diff_up) is 1.94 for Myriad but only 1.5 for DigiByte, meaning the attacker would need a slightly greater share of the hashpower to attack DigiByte.  Since DGB has a higher hash rate anyway, a successful attack seems less likely.

BTW I've updated my pull request on github.

We just saw your pull request! Thank you for contributing it! Long story short, we are vulnerable as well to the same attack if our net hash rate falls too low. But we do, however, have some additional protections built in the Myriad does not. 

We are going to issue a hard fork in the next few days. We are going to implement some changes to significantly mitigate this problem. In the mean time our chain is moving along fine, but we can use all the hash we can get. It is very likely who ever was behind the Myriad attack will attempt the same with DigiByte. And it does in fact appear that they have already tried / been trying.



Is that your polite way of saying "Thanks, but we're just gonna merge Myriad's change"?

Please do comment on these "additional protections".  As far as I can tell, the difficulty adjustment algorithm was copied verbatim from myriad, and then nMaxAdjustDown and nMaxAdjustUp were increased by a factor of 10.

"Moving along fine" is debatable when every single algorithm's difficulty regularly cycles by a factor of 10.  It just gives the illusion of moving along fine because at any given time there's usually at least 1 algorithm going through its low phase.

No, no. Not at all, we are actually compiling in your pull request as we speak to test. Just sent you a PM. Smiley
newbie
Activity: 40
Merit: 0
Since our difficulty adjustment is different than Myriad we have some more protection for this.

I don't see how that follows.  It's really the exact same thing but with max adjustments increased 10x.  Historically this has led to insane difficulty swings (even at constant hashrates) which can be difficult to distinguish from actual tomfoolery without going in and comparing timestamps. One slight advantage is that -log(max_diff_down)/log(min_diff_up) is 1.94 for Myriad but only 1.5 for DigiByte, meaning the attacker would need a slightly greater share of the hashpower to attack DigiByte.  Since DGB has a higher hash rate anyway, a successful attack seems less likely.

BTW I've updated my pull request on github.

We just saw your pull request! Thank you for contributing it! Long story short, we are vulnerable as well to the same attack if our net hash rate falls too low. But we do, however, have some additional protections built in the Myriad does not. 

We are going to issue a hard fork in the next few days. We are going to implement some changes to significantly mitigate this problem. In the mean time our chain is moving along fine, but we can use all the hash we can get. It is very likely who ever was behind the Myriad attack will attempt the same with DigiByte. And it does in fact appear that they have already tried / been trying.



Is that your polite way of saying "Thanks, but we're just gonna merge Myriad's change"?

Please do comment on these "additional protections".  As far as I can tell, the difficulty adjustment algorithm was copied verbatim from myriad, and then nMaxAdjustDown and nMaxAdjustUp were increased by a factor of 10.

"Moving along fine" is debatable when every single algorithm's difficulty regularly cycles by a factor of 10.  It just gives the illusion of moving along fine because at any given time there's usually at least 1 algorithm going through its low phase.
hero member
Activity: 924
Merit: 1000
Doesn't look like this is over:


Quote
Lawsky: NYDFS Considering Transitional BitLicense for Small Startups

Pete Rizzo (@pete_rizzo_) | Published on November 3, 2014 at 02:00 GMT   

The New York Department of Financial Services (NYDFS) has announced that it is considering creating a special type of transitional BitLicense tailored to the needs of small businesses and startups.

The special licensure would allow bitcoin startups that meet certain criteria to operate within a more flexible regulatory framework for a yet-to-be-determined period of time, during which examinations on the business would be conducted.

The formal announcement of the NYDFS’ shift in strategy came during superintendent Benjamin M Lawsky's keynote speech on the opening day of Money 20/20, an ongoing five-day conference to feature talks from other industry luminaries including Cameron and Tyler Winklevoss; Circle CEO Jeremy Allaire and Blockchain CEO Nicolas Cary, among others.

In prepared remarks, Lawsky framed his department’s decision as one that illustrates how the NYDFS is seeking to respond to criticisms it has faced from the bitcoin community during the regulation’s 90-day comment period.

Lawsky said:

    “One issue that we heard about consistently throughout the entire comment period is a concern about the compliance costs of regulation on new or fledgling virtual currency enterprises. [...] There has to be a way for startups to start up and play by the rules without getting crushed by huge compliance costs.”

In addition, Lawsky announced that the NYDFS may also seek to designate a “small group of specialized examiners” that will oversee startups and their license applications and thereby help ease the burden for startups.
Determining factors

Lawsky went on to present a list of factors that the NYDFS may consider when deciding whether to grant its proposed Transitional BitLicense.

Factors included:

    Anticipated transactional and business volume
    The mitigating risk controls already in place (eg, a bond or other insurance)
    The nature and scope of the applicant’s business
    Whether the entity is registered with FinCEN as a money services business.

Lawsky added that the NYDFS’ latest proposal was inspired by the host of letters his agency has received from the bitcoin community. Further, he remarked that he hopes the letters will soon be made public.

Lawsky remarked that he hopes the NYDFS will be able to “strike a balance” between maintaining consumer protections and enabling the bitcoin industry to grow.

“Our hope that innovative new companies – committed to doing things the right way – will want to do a lot of business in New York, the financial capital of the world,” he said.
Commitment to consumers

Throughout the remarks, Lawsky stressed that despite easing the burden for bitcoin startups, his department remains committed to protecting consumers from illicit activity.

“We cannot turn away from the vital task of preventing money laundering – which facilitates sometimes unspeakable crimes,” Lawksy said, striking a similar refrain as at the NYDFS BitLicense hearings this January.

Lawsky stressed that digital currency startups that engaged in misconduct would face significant penalties, and that all firms operating under any version of the License would have to meet strong anti-money laundering (AML) and capital standards. However, Lawsky suggested that there is a potential for startups to outsource such compliance risks, adding:

“We have faced similar issues among the smaller, community banks we regulate. We recognize that if a financial firm has 12 employees – and nine of them are compliance officers – that is not a winning business model."

Lawsky concluded by suggesting that the latest BitLicense revision would soon be made available for public comment and that a final version would be released this January.

Source: http://www.coindesk.com/lawksy-nydfs-considering-transitional-bitlicense-small-startups/
legendary
Activity: 1722
Merit: 1051
Official DigiByte Account
Since our difficulty adjustment is different than Myriad we have some more protection for this.

I don't see how that follows.  It's really the exact same thing but with max adjustments increased 10x.  Historically this has led to insane difficulty swings (even at constant hashrates) which can be difficult to distinguish from actual tomfoolery without going in and comparing timestamps. One slight advantage is that -log(max_diff_down)/log(min_diff_up) is 1.94 for Myriad but only 1.5 for DigiByte, meaning the attacker would need a slightly greater share of the hashpower to attack DigiByte.  Since DGB has a higher hash rate anyway, a successful attack seems less likely.

BTW I've updated my pull request on github.

We just saw your pull request! Thank you for contributing it! Long story short, we are vulnerable as well to the same attack if our net hash rate falls too low. But we do, however, have some additional protections built in the Myriad does not. 

We are going to issue a hard fork in the next few days. We are going to implement some changes to significantly mitigate this problem. In the mean time our chain is moving along fine, but we can use all the hash we can get. It is very likely who ever was behind the Myriad attack will attempt the same with DigiByte. And it does in fact appear that they have already tried / been trying.

newbie
Activity: 40
Merit: 0
Since our difficulty adjustment is different than Myriad we have some more protection for this.

I don't see how that follows.  It's really the exact same thing but with max adjustments increased 10x.  Historically this has led to insane difficulty swings (even at constant hashrates) which can be difficult to distinguish from actual tomfoolery without going in and comparing timestamps. One slight advantage is that -log(max_diff_down)/log(min_diff_up) is 1.94 for Myriad but only 1.5 for DigiByte, meaning the attacker would need a slightly greater share of the hashpower to attack DigiByte.  Since DGB has a higher hash rate anyway, a successful attack seems less likely.

BTW I've updated my pull request on github.
full member
Activity: 204
Merit: 100

....


I practice
I like the silence, fluffy cats and closed system blocks computers with dust filters and low noise ))

their pitiful 27 Mh/s
http://omargpools.ca/dgb/index.php?page=statistics&action=pool
 I get this:

Rig 1
gpu0 - HD 7790 - 1.7 ... 1.8  Mh/s  (-i17)
gpu1   HD 7950 - 4.1 ... 4.2  Mh/s (-i18)

cpu fx-8350
------------------

Rig 2
GPU 0 - HD 7850 - 2.6  Mh/s (-i17)
GPU1   - HD 7950 - 3.8   Mh/s (-i17)

CPU fx-8350

Rig 3
GPU 0 - HD 7850 - 2.6  Mh/s  (-i17)
GPU 1 - HD 7850 - 2.6  Mh/s  (-i17)

CPU fx-8350

Rig 4
GPU 0 - HD 7850 - 2.6  Mh/s (-i17)
GPU 1 - HD 7970 - 4.65  Mh/s (-i17)

CPU fx-8350

Rig 5
GPU0 - HD 7790 - 1.7 ... 1.8  Mh/s (-i17)

CPU fx-8350

-----------------------------------------------
it gave today 57632.27304101 DGB

As you can see, there is no overloaded ))

and all can work 24/7 in summer when the ambient temperature of 35 degrees


full member
Activity: 146
Merit: 100
Can anyone confirm that Digihash is hosted in New Jersey? I thought it was going to be in Texas or something originally but since my ping time is a lot lower than when it first went live I am going to switch over.  Plus, supporting the devs =). 

Also a thumbs up for http://birdspool.no-ip.org:5021/static/stats/ that p2pool has been rock solid and birds a cool guy that I've gotten a chance to talk to a few times.  If you are really concerned about your fees, I believe birdspool is only .5% if im not mistaken.


Its my opinion we really should be spreading the hash around by supporting the Devs pool or boosting the P2pool pools.
Jump to: