★★DigiByte|极特币★★[DGB]✔ Core v6.16.5.1 - DigiShield, DigiSpeed, Segwit

[HR]

ALSO:

I’ve got the original Myriad-Groestl srcxxx github optimized files if anyone is interesting in forking them - basically changing the name (since they’re open source to begin with) and then posting it to github. Send me a PM if you’re interested.

Hi HR, thank you for keeping us up to date with your stats. I will have a look on the original Myriad-Groestl srcxxx optimized bins. I thougt these bins only work on his pool. Maybe i can change this to get it work on every pool. Since difficulty is dropping again i could be profitable again to put a bit more power to my cards.

He originally developed two different optimized kernels that significantly increased hashrates over the previous sph-sgminer ( https://github.com/prettyhatemachine/sph-sgminer ). His miner, grs-sgminer, allowed you to use the "-k groestlcoin" switch on any pool, or the "-k optimized" switch that only worked on his pool.

My understanding is that he depreciated the github files for his original grs-sgminer that allowed you to use either switch. I could be mistaken though, but the idea that I have is that his current grs-sgminer only works with his proprietary "-k optimized" switch. If that's the case, then I think it would be interesting to fork his original grs-sgminer making available new installs once again that permit the use of any of the non-optimized kernels on any pool of the miner's choosing (grs-sgminer, using the "-k myriadcoin-groestl" switch, more than doubles the hashrate of sph-sgminer with only about a 20% increase in electrical usage - not bad at all).

https://bitcointalk.org/index.php?topic=652849.msg7503640#msg7503640

https://bitcointalk.org/index.php?topic=652849.0

I would like to correct something in the above post (it's been a while since things have been on "autopilot" and my memory didn't serve me too well, and, today, when I was putting together some stuff for DigiByte, I realized my mistake):

It was grs-sgminer's original "-k groestlcoin" kernel that doubled sph-sgminer's hashrate, not the "-k myriadcoin-groestl".

The "-k myriadcoin-groestl" kernel quadruples the original sph-sgminer's hashrate! (I even understated it to you DigiByte in the PM I sent by saying it tripled the hash rate . . . it's actually a quadruple!)

More specifically, with a 7950, sph-sgminer ran at about 5 Mh/s, grs-sgminer with -k groestlcoin at about 10 Mh/s, and grs-sgminer with -k myriadcoin-groestl has a hashrate of 20 Mh/s.

If you wouldn't mind sending me the source code I'll take a crack at it.

It's out of my hands now as it's been sent to DigiByte to use as they see fit. Perhaps you might send them a PM offering your services. 

I think it should be relatively easy to clean up (a few AV products generate alerts for the Windows exe, for example) and turn into something DigiByte official (giving credit to previous developers of course).

It's by far and away the most profitable way to mine DGB.

[24hralttrade]

It does appear someone is attempting to do something similar to DigiByte on Groestl & other algos. All appears well for the moment, but as always the more hash we can get the better.

Where do you need the hash the most, groestl? Willing to rent some to secure.

Edit: can't seem to find any groestl rentals.
Do we really need more hash to secure untill the possible upcoming hardfork?

[Kayahoga]

It's out of my hands now as it's been sent to DigiByte to use as they see fit. Perhaps you might send them a PM offering your services. 

I think it should be relatively easy to clean up (a few AV products generate alerts for the Windows exe, for example) and turn into something DigiByte official (giving credit to previous developers of course).

It's by far and away the most profitable way to mine DGB.

Groestl beats out  qubit in profitability?  I thought pools like boostpool.com were inflating the Groestl difficulty enough that it was harder to get normalized payouts.  

[HR]

This certainly seems to be wrecking havoc on the MYR blockchain. 

What are the suggested fixes for DGB?  I thought I remembered that it wasn't possible to mine more than 6 blocks in a row of a single algorithm.  Wouldn't that successfully mitigate this threat? 

From what I've been reading, the general opinion is that the most vulnerable "alts" are those that have deviated the most from the original BTC code, with the more "bells and whistles", neglect of basic security issues, and 'coders' who really don't have much of an idea about what they're doing, all leading to the most potential disaster. MYR certainly fits that bill.

Let's hope that DGB's more serious and conservative, security sensitive, and greater knowledge and know-how makes things different for us.

[HR]

It's out of my hands now as it's been sent to DigiByte to use as they see fit. Perhaps you might send them a PM offering your services. 

I think it should be relatively easy to clean up (a few AV products generate alerts for the Windows exe, for example) and turn into something DigiByte official (giving credit to previous developers of course).

It's by far and away the most profitable way to mine DGB.

Groestl beats out  qubit in profitability?  I thought pools like boostpool.com were inflating the Groestl difficulty enough that it was harder to get normalized payouts.  

My periodic postings regarding mining profitability are all groestl.

[esotericizm]

It's out of my hands now as it's been sent to DigiByte to use as they see fit. Perhaps you might send them a PM offering your services. 

I think it should be relatively easy to clean up (a few AV products generate alerts for the Windows exe, for example) and turn into something DigiByte official (giving credit to previous developers of course).

It's by far and away the most profitable way to mine DGB.

Why make me chase the dev's?

[Arsenay]

It's out of my hands now as it's been sent to DigiByte to use as they see fit. Perhaps you might send them a PM offering your services. 

I think it should be relatively easy to clean up (a few AV products generate alerts for the Windows exe, for example) and turn into something DigiByte official (giving credit to previous developers of course).

It's by far and away the most profitable way to mine DGB.

Groestl beats out  qubit in profitability?  I thought pools like boostpool.com were inflating the Groestl difficulty enough that it was harder to get normalized payouts.  

I tried everything
qubit is best for my hd 7xxx: 7970 7950 7850 7790
cold and less diff
and more profit
and all of this perfectly clear here:
https://dgb-qubit.theblocksfactory.com

[HR]

It's out of my hands now as it's been sent to DigiByte to use as they see fit. Perhaps you might send them a PM offering your services.  

I think it should be relatively easy to clean up (a few AV products generate alerts for the Windows exe, for example) and turn into something DigiByte official (giving credit to previous developers of course).

It's by far and away the most profitable way to mine DGB.

Groestl beats out  qubit in profitability?  I thought pools like boostpool.com were inflating the Groestl difficulty enough that it was harder to get normalized payouts.  

I tried everything
qubit is best for my hd 7xxx: 7970 7950 7850 7790
cold and less diff
and more profit
and all of this perfectly clear here:
https://dgb-qubit.theblocksfactory.com

Qubit is a distant second, and, even though electrical usage is more or less the same, my cards heat up much more than with groestl. All things considered, groestl is the clear winner in my opinion. How do your Qubit proceeds match the Groestl proceeds depicted below?

57 Day Chart - DGB (and BTC equivalent) Daily Mining Proceeds for each 1 MH/s

Check out how your BTC equivalent proceeds have stayed constant – for a variety of reasons, but mainly because as price falls, mining falls, and difficulty falls, giving the miner more DGB rewards, and thusly keeping the BTC equivalent steady. Interesting observation I thought.

It's also always at the top of the list at http://www.whattomine.com/ . Qubit gives Skein a close run for that distant second.

[Kayahoga]

I have 2 rigs that together use 920 watts and get me about 75-80k DGB per day when running Qubit.

Edit:  This is with my cards being undervolted and running the engine clock at 1050 / mem clock at 1500.  I have a mix of 280x / 270x

[Kayahoga]

It's also always at the top of the list at http://www.whattomine.com/ . Qubit gives Skein a close run for that distant second.

Do you use the default parameters or do you enter data that matches your cards for http://whattomine.com?


Especially given the attacks on Groestl im thinking I need to switch from qubit to groestl.

[HR]

It's out of my hands now as it's been sent to DigiByte to use as they see fit. Perhaps you might send them a PM offering your services. 

I think it should be relatively easy to clean up (a few AV products generate alerts for the Windows exe, for example) and turn into something DigiByte official (giving credit to previous developers of course).

It's by far and away the most profitable way to mine DGB.

Why make me chase the dev's?

Because the Dev's expressed an interest in making it DGB official. That's a good thing. It'll give clout to the miner eventually released, and will also add to DigiByte's resume as it were.

Anyone who wants to download the current grs-sgminer (warts and all) that let's you use the -k myriadcoin-groestl kernel can do so by downloading the AidBit wallet http://www.aidbit.net/download/ (be sure to disable your AV beforehand) which installs the windows version along with the wallet install (I believe this is still correct anyway). Then, you'll need to locate your miner install, and independently configure appropriately. For everyone else, I suggest waiting for the DigiByte team to release a new, improved dgb-groestl-sgminer. The Linux version already looks great and ready to go as is, and just needs to be renamed and uploaded to github. The Windows version needs a couple of tweaks and to be made official . . . I think anyway.

I only have remedial code reading abilities, and am not a programmer by any means.

[HR]

It's also always at the top of the list at http://www.whattomine.com/ . Qubit gives Skein a close run for that distant second.

Do you use the default parameters or do you enter data that matches your cards for http://whattomine.com?


Especially given the attacks on Groestl im thinking I need to switch from qubit to groestl.

The default parameters are based on the -k groestlcoin kernel, and even then, groestl is always fighting for the top spot. With MYR even more so. I change the parameters to meet with the -k myriadcoin-groestl kernel, and that's double the -k groestlcoin.

Here's something else that looks fairly reliable: https://docs.google.com/spreadsheets/d/1OdhCDxtDtLLuW-dK4hfIrD55c2nBGXbBonG0haBJB0o/edit#gid=0  That groestl data is also based on the simple -k groestlcoin kernel analysis . . . so double what you see there and . . .

BTW: https://dgb-groestl.theblocksfactory.com/ hashrate has shot up by 10x in the last 24 hours. Must be everyone who was on cryptopoolmining. Boostpool is still hammering away too.  

Edit:

People in the U.S. should also seriously consider http://birdspool.no-ip.org:5021/static/stats/ - it's reliable and honest; you just have to wait for the rolling payouts to ramp up (and the other side of that coin is that you continue to receive payouts for the rolling payout period even after you've left!). The new, official, DigiByte NOMP pools look good too.

[Kayahoga]

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.

[Arsenay]

....

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

[MentalCollatz]

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.

[DigiByte]

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.

[ycagel]

Doesn't look like this is over:

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/

[MentalCollatz]

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.

[DigiByte]

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.

[HR]

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