Status: 0/unconfirmed Date: 8/7/2013 11:56 To: btce DCfat2uXzgYuYLrmCLUi1J5jBFe3Y9a6HL Debit: -5560.00 DGC Net amount: -5560.00 DGC Transaction ID: 3a123a75c463daa9da91eae065880680e3ce94ef67cf94d797fee576ecb6656f 4 hours and 0 confirmation  To BTC-e? Really? |
|
|
|
Network hashrate: 316.84 MH/s
Current difficulty
4.5503
Next difficulty
1.8623
Is again some coin-switching pool jumping on dgc?
Again? It did not stopped |
|
|
|
|
Ok and is the problem over now? Safe to mine at your pool? What measures has been taken, that it will not repeat again?
|
|
|
|
|
Status: 49 potvrzení, broadcast through 3 node(s)
Date: 5.8.2013 17:41
To: DGC Donations DHgXvhswV9j3t9VTKu1QfAu6kYM1HHD5sJ
Debit: -2000.00 DGC
Transaction fee: -0.05 DGC
Net amount: -2000.05 DGC
Transaction ID: 8e7da741d900fea3eb99fedf9bb9caa68560faeb9857932c7fe4b127c0be738b
|
|
|
|
|
I have got a question. Is this bank taking some legal issues into concern? Some money laundering prevention in DGC exchange? Several exchanges had problem with this. Traditional bank needs to have a license, although this will not be a traditional bank, is it legal?
|
|
|
|
|
What much time do you estimate will take to fix the current pool issue?
|
|
|
|
Are you the dev of DGC or are you its price manipulator? I could have swore in a past post you said you're not THE dev but rather a volunteer. And now you want to change DGC into the biggest premined coin in all history of premined coins. Congrats, you have turned what's supposed to be a decentralized system into a centralized one.
By the way, how's that mining contract of yours coming along? You still mining other coins instead of DGC?
Respectfully, the fact you would even consider this shows how clueless you are...
-Merc
I would wonder how it could be turn to centralized system? Not to mention other nonsenses you are writing about. Where do you guys get all those sh*ts? Do you have some kind of random stupid sentence generator or somethink like that? |
|
|
|
|
Then i vote for no decrease.
This can't fix the problem. Even with lower rewards, DGC can (and will) repeatably became most profitable coin on sites like coinchoose.com. Then profit switching miners and pools will arrive again... And problem will be back. European Union does these kind of solutions... It is short-term solution.
I still believe innovative diff adjustment is the key.
|
|
|
|
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. |
|
|
|
|
What is the motivation to decrease it?
|
|
|
|
Wait for me  Status: 0/nepotvrzeno, broadcast through 30 node(s) Date: 27.7.2013 10:49 To: DGC Donations DHgXvhswV9j3t9VTKu1QfAu6kYM1HHD5sJ Debit: -2000.00 DGC Transaction fee: -0.03 DGC Net amount: -2000.03 DGC Transaction ID: 362e9e2c6148bec623dc064dd773e13d01d36c1c147e1cd6b4b1bc1bdc23bb85 |
|
|
|
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... |
|
|
|
I'd like to mine this a bit, but your setup instructions are pretty confusing (your average windows noob here). Could someone post an example of what the text of a solo mine argentum.conf file would look like. (.conf for cgminer would help too). Thanks. Edit: -" http://p2poolmining.org:8012/static/" fails to resolve. http://p2poolmining.org:8012 works though. example: rpcuser=Duffer
rpcpassword=Duffer1
rpcport=13581
server=1
addnode=174.111.237.246
addnode=5.135.161.23
addnode=71.187.248.95
addnode=24.138.46.123
example: cgminer --scrypt -o 127.0.0.1:13591 -u Duffer -p Duffer1 -o stratum+tcp://mine-arg.scryptmining.com:3335 -u ... -p ... -o stratum+tcp://arg.epools.org:3339 -u ... -p ... -Q 0 -E 3 -s 1
|
|
|
|
I was getting much lower solo mining. Let's see what happens once we have stable hash.
When will it be? |
|
|
|
Lets see the havoc in which ARG will be left in approx 10 minutes
Agree. This is just a proof that ARG should get more support from miners. It is not just a pump and dump coin. Leaving network at this disproportionately diff isn't motivating for miners. |
|
|
|
|
Lets see the havoc in which ARG will be left in approx 10 minutes
|
|
|
|
This multipool bastard is really starting to piss me off. He is playing with my money and that's not funny anymore. If there is someone with experience performing DDoS, please contact me in private message.  I support you 100%, but there is also alternative solution. They have much lover influence on DGC for example, because nw hash rate is much higher than their 400MH/s. So if we bring ARG network 400+ they will not have so devastating influence like few days backward. We have to support the coin by mining it. ARG is rare coin and it should have great value in the future, so why just sit and cry, let us do something about it. I already throw all my hash power to ARG in order to support coin and great team behind Baritus and other devs. I want to do something about it. I am mining DGC from beginning with occasional switching to ARG, becasuse i trust in both coins. But i can't even reasonably mine. Mining ARG at diff so high, can't even cover my expenses. Then this guy, raiding this coin, makes most miners just leave mining ARG which leaves network hashrate at 7MH/s. Then after diff adjustment raid again... This scenario repeats few times...The real damage is that many of the miners won't get back. Many of them do not have time or nerves to check every diff adjustment if network was left fucked up after bastards raid or if its at least for a bit worth mining. Its ok if network hashrate suddenly rises 10,20, 100 times and then drops, but not periodicaly. Personally i consider this an attack, because there is no concern from attacker if it is harmful for coin. He simply does not care. Luckily I have no problem put myself to the same moral level as an attacker and attack back with same or worse, when i see that he does not care. |
|
|
|
This multipool bastard is really starting to piss me off. He is playing with my money and that's not funny anymore. If there is someone with experience performing DDoS, please contact me in private message. |
|
|
|
|
Show Posts
