[ANN][DGC] Digitalcoin | Multi-algo & Masternodes | Established 2013

[alatvian]

I have been doing solo mining of DGC over the last few days, just to see if it was still possible for ANY mere law-abiding mortal to solve a block in ANY coin.  I was happy to see this scroll by in the logs:

Code:

(5s):179.3K (avg):178.5Kh/s | A:0  R:1  HW:0  U:0.0/m  WU:149.5/m
 [2013-07-24 17:39:30] New block detected on network
(5s):179.2K (avg):178.5Kh/s | A:0  R:1  HW:0  U:0.0/m  WU:149.5/m
 [2013-07-24 17:39:38] Found block for pool 0!
(5s):168.4K (avg):178.5Kh/s | A:0  R:1  HW:0  U:0.0/m  WU:181.5/m
 [2013-07-24 17:39:39] Accepted 00002c38 Diff 379K/177551 BLOCK! GPU 0
GPU0                | (5s):178.4K (avg):178.5Kh/s | A:1 R:1 HW:0 U:0.0/m I:16

Looks like I solved a block, doesn't it?  It wasn't rejected (I did solve one that was rejected a day earlier, hence the R:1).  Well, I didn't get any reward for it.  Did I not set something right?  I checked debug.log from digitalcoind, and see this:

Code:

BitcoinMiner:
proof-of-work found  
  hash: 000000002c38aca1da8e0b3e8d6893749dfb97e40ad88d0c880d7aa73fdbab5a  
target: 000000005e7d9e00000000000000000000000000000000000000000000000000
CBlock(hash=0adb0a7d32a5a1aceeae, PoW=000000002c38aca1da8e, ver=1, hashPrevBlock
=9a30614659eef28a0004, hashMerkleRoot=c45b777403, nTime=1374701973, nBits=1c5e7d
9e, nNonce=1333068544, vtx=1)
  CTransaction(hash=c45b777403, ver=1, vin.size=1, vout.size=1, nLockTime=0)
    CTxIn(COutPoint(0000000000, -1), coinbase 049549f0510105062f503253482f)
    CTxOut(nValue=20.00000000, scriptPubKey=03429e20f2cdf0b8eb6cf6f859cef2)
  vMerkleTree: c45b777403 
generated 20.00
keypool keep 5
AddToWallet c45b777403  new
NotifyTransactionChanged c45b7774033fde11e79e928fbc84ced1a703d1afa9648a54069ae59b2c4139d2 status=0
updateWallet c45b7774033fde11e79e928fbc84ced1a703d1afa9648a54069ae59b2c4139d2 0
SetBestChain: new best=0adb0a7d32a5a1aceeae  height=285964  work=3674388140234825  date=07/24/2013 21:39:33
ProcessBlock: ACCEPTED

Checking the transaction http://dgc.cryptocoinexplorer.com/tx/c45b7774033fde11e79e928fbc84ced1a703d1afa9648a54069ae59b2c4139d2 shows coins going to DDiANqEpnKHfhY5dLhPRadVN325GjfCUFB, which I've never heard of.  What gives?

[1714055464]

1714055464

[1714055464]

1714055464

[1714055464]

1714055464

[jamestown2035]

Any good pools to mine this coin at?  digicoinpool from litebonk or bigvern is a joke. Consistently getting about half the coins I should be earning.  These scam pools need to be outed.  

[ahmed_bodi]

you do realise that the figures given are approximations right? they dont include orphans, stales and pool luck. Perhaps you should try running a pool then put up with the hassle of maintenance and being called a scammer

[alatvian]

you do realise that the figures given are approximations right? they dont include orphans, stales and pool luck. Perhaps you should try running a pool then put up with the hassle of maintenance and being called a scammer

So if my the server says I found a block, and the miner says I found a block, and the network accepts it, it still might be bogus?  That doesn't sound right.  Winner gets the reward.  Has anyone within the sound of my text ever gotten a reward with solo mining, and can you tell me what (if anything) I did wrong?

[smscotten]

you do realise that the figures given are approximations right? they dont include orphans, stales and pool luck. Perhaps you should try running a pool then put up with the hassle of maintenance and being called a scammer

So if my the server says I found a block, and the miner says I found a block, and the network accepts it, it still might be bogus?  That doesn't sound right.  Winner gets the reward.  Has anyone within the sound of my text ever gotten a reward with solo mining, and can you tell me what (if anything) I did wrong?

I don't think he was replying to you.

Your situation does look strange. When I've solo mined, I've seen new addresses generated for me, but I saw those new addresses for the first time when the block's balance appeared in my wallet.

Since it hasn't been redeemed I have to wonder if that's an address of yours that you didn't know you had by virtue of it being created for you. Are you mining through the same wallet you use for other things?

[CartmanSPC]

Any good pools to mine this coin at?  digicoinpool from litebonk or bigvern is a joke. Consistently getting about half the coins I should be earning.  These scam pools need to be outed.  

Try out http://dgc.xpool.net:8810/

Any blocks found are paid to you immediately. No having to wait for pool confirmations or pay a cash out fee. Very hard for the pool operator to cheat you out of your share. No fear of having coins stolen from the pool wallet as it never holds any.

It accurately tells you what your expected payout will be if a block is found.

[alatvian]

Since it hasn't been redeemed I have to wonder if that's an address of yours that you didn't know you had by virtue of it being created for you. Are you mining through the same wallet you use for other things?

Yep, I just used the same wallet I just used to transfer some coins to cryptsy.  And it might be a new address, but I cannot find this anywhere in digitalcoin-qt interface. 

[smscotten]

Yep, I just used the same wallet I just used to transfer some coins to cryptsy.  And it might be a new address, but I cannot find this anywhere in digitalcoin-qt interface. 

I dunno. When what I described happened the address didn't appear in my address book but the balance was in my transaction history. I'm just saying that the unrecognized address might not be anything bad by itself. Not showing in your transaction history, obviously that is bad but I'm fresh out of clue.

[erk]

I hope you are watching this thread about the recent attack on trc to learn from it in order to protect dgc in the future:

www.bitcointalk.org/index.php?topic=261986.0

Like most coins DGC diff recalculate time is too long to avoid those kind of attacks. TRC diff recalculate is much faster than DGC, and yet TRC is now stuck on a stupidly high difficulty at just 12.15% profitability so nobody will want to mine it.

The entire concept of reducing difficulty based on a block count is out of touch with what really happens after a burst of high hash rate. The idea needs to be thrown out and replaced with a system based on elapsed time, or some other metric.

All these systems look at the velocity of blocks being created, not the acceleration and deceleration of the block rate which is critical.

I totally agree. I have recently sent Baritus private message about this, but unfortunately no response yet - But his time is precious these days

I think diff should be adjusted based on network hashrate. If current network hasrate is k% higher/lower then it was in previous diff ajdustment, it should be adjusted. Of course it could be more inteligent (progressive adjustment, moving average, future hashrate prediction, etc..)

Value of k can be adjusted dynamicly too, based on current conditions.
For Example:
if network hashrate is less then 1GH/s it can be 10%
if network hashrate is less then 10Gh/s it can be 5%
if network hashrate is less then 100Gh/s it can be 1%
etc...

How are you going to work out what the network hash rate is at the time? Currently that's done by counting blocks.


My solution to the hash rate burst problem is simple, reject blocks that try to be added to the chain faster than a predetermined rate. So you are introducing a minimum gap between blocks.

Say a DGC miner finds a new block and want's to submit it to the block chain, the digitalcoind would check the current time against the timestamp on the newest block of the chain and if less than 15sec had elapsed, it would not submit the block.  Also the copies of digitalcoind peering, would not accept any blocks to be added to the chain unless their timestamp was at least 15 higher than the highest timestamp in their copy of the block chain, but not higher than the current time. (to avoid cheats)   For ARG you would probably make it a 25 sec minimum gap between blocks.


You would need to calculated difficulty slightly differently, it would be based on the ratio of blocks that were submitted exactly at the 15sec mark rather than the 20sec target. Some testing and tuning would be requited. 15secmin between blocks might be too long for a good difficulty calculation, perhaps 10sec.

[Lloydimiller4]

I hope you are watching this thread about the recent attack on trc to learn from it in order to protect dgc in the future:

www.bitcointalk.org/index.php?topic=261986.0

Like most coins DGC diff recalculate time is too long to avoid those kind of attacks. TRC diff recalculate is much faster than DGC, and yet TRC is now stuck on a stupidly high difficulty at just 12.15% profitability so nobody will want to mine it.

The entire concept of reducing difficulty based on a block count is out of touch with what really happens after a burst of high hash rate. The idea needs to be thrown out and replaced with a system based on elapsed time, or some other metric.

All these systems look at the velocity of blocks being created, not the acceleration and deceleration of the block rate which is critical.

I totally agree. I have recently sent Baritus private message about this, but unfortunately no response yet - But his time is precious these days

I think diff should be adjusted based on network hashrate. If current network hasrate is k% higher/lower then it was in previous diff ajdustment, it should be adjusted. Of course it could be more inteligent (progressive adjustment, moving average, future hashrate prediction, etc..)

Value of k can be adjusted dynamicly too, based on current conditions.
For Example:
if network hashrate is less then 1GH/s it can be 10%
if network hashrate is less then 10Gh/s it can be 5%
if network hashrate is less then 100Gh/s it can be 1%
etc...

How are you going to work out what the network hash rate is at the time? Currently that's done by counting blocks.


My solution to the hash rate burst problem is simple, reject blocks that try to be added to the chain faster than a predetermined rate. So you are introducing a minimum gap between blocks.

Say a DGC miner finds a new block and want's to submit it to the block chain, the digitalcoind would check the current time against the timestamp on the newest block of the chain and if less than 15sec had elapsed, it would not submit the block.  Also the copies of digitalcoind peering, would not accept any blocks to be added to the chain unless their timestamp was at least 15 higher than the highest timestamp in their copy of the block chain, but of course not higher than the current time, to avoid forgeries.   For ARG you would probably make it a 25 sec minimum gap between blocks.

I think that might be a very effective way of solving both the 51% attack problem and the coin hopping miner problem

[erk]

My solution to the hash rate burst problem is simple, reject blocks that try to be added to the chain faster than a predetermined rate. So you are introducing a minimum gap between blocks.

Say a DGC miner finds a new block and want's to submit it to the block chain, the digitalcoind would check the current time against the timestamp on the newest block of the chain and if less than 15sec had elapsed, it would not submit the block.  Also the copies of digitalcoind peering, would not accept any blocks to be added to the chain unless their timestamp was at least 15 higher than the highest timestamp in their copy of the block chain, but of course not higher than the current time, to avoid forgeries.   For ARG you would probably make it a 25 sec minimum gap between blocks.

I think that might be a very effective way of solving both the 51% attack problem and the coin hopping miner problem

I came up with the idea trying to partially solve the 51% problem, but more so to get some stability into the block rate, these fluctuations are driving me nuts.

It wont totally solve the 51% problem, but it should make it a lot harder, and it should discourage the attacks we have seen on FTC/TRC and others.

[smscotten]

Any good pools to mine this coin at?  digicoinpool from litebonk or bigvern is a joke. Consistently getting about half the coins I should be earning.  These scam pools need to be outed.  

Try out http://dgc.xpool.net:8810/

It's only been a few hours so it's too soon to have meaningful numbers, but over the last few hours xpool has returned about 8:5 what bigvern's pool did per hour. And I have another machine still on bigvern's pool so the test is unfairly stacked in bivern's favor. So I'm surprised to admit that jamestown2035's "half" isn't hyperbole.

[baritus]

Hello,

Make yourselves heard by voting: https://bitcointalk.org/index.php?topic=263417.0

Also, we are running a fund raiser event that also gives you shares in upcoming Bank/Exchange, check that out here: https://bitcointalk.org/index.php?topic=262648.0

Thank you

[disclaimer201]

History will not look back kindly at digitalcoin if the dev arbitrarily decides to reduce the block reward to increase scarcity and please investors.

I completely agree. It's already happening with WDC.

I'll be really disappointed if DGC follows suit.

^^this

[baritus]

History will not look back kindly at digitalcoin if the dev arbitrarily decides to reduce the block reward to increase scarcity and please investors.

I completely agree. It's already happening with WDC.

I'll be really disappointed if DGC follows suit.

^^this

The reason for doing it would be the unexpected arrival of profit switching miners and pools. This change means a large portion of the alt coin hash power are uninvolved profit seekers. When deciding on the current rate, that was not taken into consideration. These miners do not hold like regular miners do and so are having a disproportionately negative effect on the currency.

Also, I will never make an arbitrary decision over matters that affect others in the community. Voting is the common mechanism.

[Xmansk]

How are you going to work out what the network hash rate is at the time? Currently that's done by counting blocks.


My solution to the hash rate burst problem is simple, reject blocks that try to be added to the chain faster than a predetermined rate. So you are introducing a minimum gap between blocks.

Say a DGC miner finds a new block and want's to submit it to the block chain, the digitalcoind would check the current time against the timestamp on the newest block of the chain and if less than 15sec had elapsed, it would not submit the block.  Also the copies of digitalcoind peering, would not accept any blocks to be added to the chain unless their timestamp was at least 15 higher than the highest timestamp in their copy of the block chain, but not higher than the current time. (to avoid cheats)   For ARG you would probably make it a 25 sec minimum gap between blocks.


You would need to calculated difficulty slightly differently, it would be based on the ratio of blocks that were submitted exactly at the 15sec mark rather than the 20sec target. Some testing and tuning would be requited. 15secmin between blocks might be too long for a good difficulty calculation, perhaps 10sec.

I think currently it is done by averaging time between blocks. Don't know how large the window is, but it can be lowered. For example averaging time between last 15 blocks. This way diff can adjust quickly to network hashrate growt, but not quickly enough (i mean quickly in time, not in number of blocks found) to network hashrate fall. But it is still much better the current diff adjustment algorhitm. Maybe there can be one alghoritm for computing diff increase and second alghoritm to compute diff decrease. Or 2 alghoritms for calculating next diff, and then diff will be adjusted based on result from both algorhitms. It is not computationally demanding to do so.


Regarding your solution. It could work. But DGS's 20s per block is just statisticaly. It can be found in 5s, or in 1 minute to, but when you take time between last for example 1000 blocks it should be ~20s per block. So your solution will sometimes reject completely valid blocks. But if you think of it as minimum gap between last n block, it could work.

[teiva]

History will not look back kindly at digitalcoin if the dev arbitrarily decides to reduce the block reward to increase scarcity and please investors.

I completely agree. It's already happening with WDC.

I'll be really disappointed if DGC follows suit.

^^this

The reason for doing it would be the unexpected arrival of profit switching miners and pools. This change means a large portion of the alt coin hash power are uninvolved profit seekers. When deciding on the current rate, that was not taken into consideration. These miners do not hold like regular miners do and so are having a disproportionately negative effect on the currency.

Also, I will never make an arbitrary decision over matters that affect others in the community. Voting is the common mechanism.

IMO, cutting reward by half (50%) is dangerous.

If DGC mining doesn't get profitable, lots of miners will fallback on another alt coin.

This could lead to panic selling on the currency, that will lead to even less profitability. And so on...

I think DGC (with current reward ans stales ajustment) is just as profitable as LTC (i switch my miners regularly between both currencies)

If you cut mining rewards by half, i dunno if i would continue mining DGC (even if i really believe in this coin's future !)

Well, that's just my (newbie) opinion :-)

All the best for your future projects (bank/exchange)

[digitalindustry]

History will not look back kindly at digitalcoin if the dev arbitrarily decides to reduce the block reward to increase scarcity and please investors.

I completely agree. It's already happening with WDC.

I'll be really disappointed if DGC follows suit.

^^this

The reason for doing it would be the unexpected arrival of profit switching miners and pools. This change means a large portion of the alt coin hash power are uninvolved profit seekers. When deciding on the current rate, that was not taken into consideration. These miners do not hold like regular miners do and so are having a disproportionately negative effect on the currency.

Also, I will never make an arbitrary decision over matters that affect others in the community. Voting is the common mechanism.

why do you want to play with the market ?-

Why don't you guys have any attention span? , this is a market mechanism.

Why don't you people understand anything about basic economics  ?

Can i get a confirmation on weather this is going to take place so i can sell what i have .


There is no way in which what so ever to manipulate hash expect in an informational manner - if the currency gets "stuck in difficulty" then it is , what needs to occur is a trend towards security , other than strictly hash - this was in some ways done with PoS - but its not the only option .

there are other ways , but i depends on what one's aims are .

[disclaimer201]

Again, I would agree with the concerns simply because you shouldn't change the rules of the game while people are already playing it, especially if there was no urgent need for such a change other than profit. It will undo all of your efforts to make DGC have a fair start, which I found awesome because now everyone who comes after the early adopters gets screwed over. This might be seen as sort of a "premine" for anyone who will discover DGC at some point in the future.

Another issue is one shouldn't try to force success of a coin since this is a probably futile approach, either it will be successful on its own, or it will fail. Poll or not, you cannot ask future miners about their opinion, so let's leave things as they are, work toward more actual incentives for people to switch over to DGC and develop services. For public relations matters it will be very important how to market the strength of DGC in contrast to other coins.

I want to be able to have very clear and convincing information if I chat with someone on btc-e, and for myself as why I should believe in digitalcoin and mine it. "Why did I choose DigitalCoin and not fast coin?" I usually say, 12 second blocks are way too short, the orphan rate will just be too high. "What makes dgc not just another crap coin out there, they are all the same!" I would usually say it will be much better to use for merchants and if it has enough hashpower in the future, it might even address the PoS problem, because clearly 20 seconds a block is very fast and your usually waiting longer in line to pack your bags, or have them pack your bags for you. There are other reasons for why a scrypt coin, and not sha-256...and it just goes on. The strong community support is another reason to choose DGC.

And that's why it's important to ensure the community is in full agreement of any changes, but not just the current community, but the future one as well. There are more people needed to make DGC a success that do not know about DGC yet than there are people backing it right now. Baritus, make me believe in it, and others will believe in it too!

disclaimer201

started mining bitcoins in June 2011,
mined bitcoins in November and December 2011,
started mining litecoins in June 2012,
mined litecoins until July 2013,
started mining digitalcoins.

[baritus]

I'm just gauging community opinion with the poll, you can be assured no decisions are ever made in this community without input from all members. I definitely see both sides of the argument and I am currently siding with keeping it as is or a slight decrease (10-20%).
 
Nevertheless, polls are one of the few ways of gathering information so don't be surprised to see them coming up. It doesn't mean anything but an opinion gauge.

Good discussion, if anyone has anything else to add, please do.