Bitcoin Forum
December 14, 2017, 11:05:58 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 [109] 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 »
  Print  
Author Topic: ⚒[CGA] Cryptographic Anomaly - The Elusive Coin⚒  (Read 224554 times)
Cor2
Hero Member
*****
Offline Offline

Activity: 595


View Profile
March 18, 2014, 10:24:34 PM
 #2161

We are there! Has anyone forked? I really hope not!
good good good excellent all at the pool we already have 1/4 found/amount
Ever since passin block 64k I see the following:
- about 3 times more blocks found reported on pools (which previously ignored zero-reward blocks) (this is expected)
- I see many blocks being rewarded 0.33 CGA, but there seems to be *no* relation to the difficulty of that block!
Several blocks have very low difficulty (1.11 or 1.16 or 1.60) and have a *lower* reward (0.23, 0.22, 0.16)
while I also see blocks found with diff larger than 3 which *do* have 0.33 rewards!
It appears that the reward is not calculated from the actual diff at the moment of block finding, or the pool is mis-reporting it?

So, I went to the block explorer and checked one suspect: block 64090:
difficulty  1.10575869
TX Value  0.22609161
Oh-oh...
Block Time: 40 seconds
Difficulty Refresh: 80 seconds/2 blocks
1/diff next 2 block
Ya the diff will reflect the next block not the current one... I'm not sure how to change such a thing.
Ah, that clarifies.
The block finding time is now 60 sec (30 blocks found in 30 mins from block 64115 to 64145) so still not near the designed 40 sec.
The diff seems not to jump as high as before any more, but apparently still enough to cause some blocks to take several minutes to be found, slowing the average down quite a bit.

SYNC: Sd3XBRmhrrr39Wj4rtjb3YAkwWvCze44BZ                    ORB: odyWi677JDQy7Gc6Nv6kCdnajmScqgTkDE       Honest pools (payout matching calculation):
TransferWise: International money transfer for 1%fee        Doge to the moon! D9FGY7Bhwbj2jrnk7v8VR47HTu7vfVu1gV         Nut2pools and Steadymining
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1513292758
Hero Member
*
Offline Offline

Posts: 1513292758

View Profile Personal Message (Offline)

Ignore
1513292758
Reply with quote  #2

1513292758
Report to moderator
1513292758
Hero Member
*
Offline Offline

Posts: 1513292758

View Profile Personal Message (Offline)

Ignore
1513292758
Reply with quote  #2

1513292758
Report to moderator
s4w3d0ff
Sr. Member
****
Offline Offline

Activity: 322


Spray and Pray


View Profile
March 18, 2014, 10:34:27 PM
 #2162

We are there! Has anyone forked? I really hope not!
good good good excellent all at the pool we already have 1/4 found/amount
Ever since passin block 64k I see the following:
- about 3 times more blocks found reported on pools (which previously ignored zero-reward blocks) (this is expected)
- I see many blocks being rewarded 0.33 CGA, but there seems to be *no* relation to the difficulty of that block!
Several blocks have very low difficulty (1.11 or 1.16 or 1.60) and have a *lower* reward (0.23, 0.22, 0.16)
while I also see blocks found with diff larger than 3 which *do* have 0.33 rewards!
It appears that the reward is not calculated from the actual diff at the moment of block finding, or the pool is mis-reporting it?

So, I went to the block explorer and checked one suspect: block 64090:
difficulty  1.10575869
TX Value  0.22609161
Oh-oh...
Block Time: 40 seconds
Difficulty Refresh: 80 seconds/2 blocks
1/diff next 2 block
Ya the diff will reflect the next block not the current one... I'm not sure how to change such a thing.
Ah, that clarifies.
The block finding time is now 60 sec (30 blocks found in 30 mins from block 64115 to 64145) so still not near the designed 40 sec.
The diff seems not to jump as high as before any more, but apparently still enough to cause some blocks to take several minutes to be found, slowing the average down quite a bit.

This will continue until the network hash gets a bit higher. Like I said before we had Kimotos Gravity Well before but there are exploits that involve nTime, until someone comes up with a better solution, the only thing that will stabilize the block time is more people mining. So spread the word!

BTC:15D8VaZco22GTLVrFMAehXyif6EGf8GMYV
|⚒|Cryptographic Anomaly|⚒|
hoosen
Member
**
Offline Offline

Activity: 89


View Profile
March 18, 2014, 11:11:51 PM
 #2163

I made a manual payout request over 24hrs+ ago at cga.inceptioncraft.net and have not received it yet. What the freak is taking so long?
Also have coin that have sat unconfirmed for about the same time with them as well.
There was a fork, so depending where it is sent from/to, it may or may not arrive and your actions can recover your control over these coins.
Where did you send the coins to? Are you sure that the receiving end was on the correct block chain (else it will never show up, even though
it was properly sent and recorded in the block chain).
Note that your coins do not reside in a wallet, they only are recorded in the block chain, your wallet is just a window into the block chain
to see and manipulate the coins registered under one or more addresses that the wallet generated for you.
If you follow the link from the transactoin on InceptionCraft, to the block of the block chain, you should see that it has hundreds of confirmations, showing that it is a valid block from the main block chain (not an orphaned fork).
If you have coins that have showed up in a wallet that have been sitting unconfirmed for hours, that means that those coins were sent
from an address that was on the *forked* chain and they are not recognised by other nodes, so they do not get confirmations.
If those coins were mined *while* on the forked chain, then those coins do not officially exist and they will never be confirmed,
because they were created with an invalid block chain.
If those coins were created before the fork and were only *transferred* while the wallet was on the forked chain, then they officially
never were sent!
That means that as far as the block chain is concerned, those coins are still in the "sending" wallet and not in the receiving one, that is
why there are no confirmations - the transactoin never happened on the official block chain.
You can recover in various ways from this - rescanning the wallets and a few other ways, the most involved but powerful way is to export
the private keys from the wallets that are affected and making a wallet backup,
then install a new fresh wallet, then import the private key(s) into the new wallet.
All the transactoins associated with those keys (= CGA addresses) are now read from the official block chain, so anything that
happened on the fork will never show up in the wallet and the sending wallet should have the balance again that was sent on the fork.
Hope this helps!

I sent the CGA from my inceptioncraft pool account to my CGA wallet. Ive redownloaded the block chain am on running the most up to date CGA wallet and have even sent coins from other pools to my wallet and had them confirmed.

The coins in my inceptioncraft pool account have all confirmed except the last payout which was probably mined on the forked block chain which is fine its only like .07cga. But the rest is confirmed and has not been received in my CGA wallet after making the payout request.

There is no transaction of the coins being sent to my wallet from inceptioncraft in my wallet nor inceptioncraft transaction records.

Its like inceptioncraft just never sent them to me.

MUE:7Qt2Tue6RcWCA2GJhWHehS5783D62MSB2S
tf2honeybadger
Full Member
***
Offline Offline

Activity: 189


View Profile
March 18, 2014, 11:29:13 PM
 #2164

I made a manual payout request over 24hrs+ ago at cga.inceptioncraft.net and have not received it yet. What the freak is taking so long?
Also have coin that have sat unconfirmed for about the same time with them as well.
There was a fork, so depending where it is sent from/to, it may or may not arrive and your actions can recover your control over these coins.
Where did you send the coins to? Are you sure that the receiving end was on the correct block chain (else it will never show up, even though
it was properly sent and recorded in the block chain).
Note that your coins do not reside in a wallet, they only are recorded in the block chain, your wallet is just a window into the block chain
to see and manipulate the coins registered under one or more addresses that the wallet generated for you.
If you follow the link from the transactoin on InceptionCraft, to the block of the block chain, you should see that it has hundreds of confirmations, showing that it is a valid block from the main block chain (not an orphaned fork).
If you have coins that have showed up in a wallet that have been sitting unconfirmed for hours, that means that those coins were sent
from an address that was on the *forked* chain and they are not recognised by other nodes, so they do not get confirmations.
If those coins were mined *while* on the forked chain, then those coins do not officially exist and they will never be confirmed,
because they were created with an invalid block chain.
If those coins were created before the fork and were only *transferred* while the wallet was on the forked chain, then they officially
never were sent!
That means that as far as the block chain is concerned, those coins are still in the "sending" wallet and not in the receiving one, that is
why there are no confirmations - the transactoin never happened on the official block chain.
You can recover in various ways from this - rescanning the wallets and a few other ways, the most involved but powerful way is to export
the private keys from the wallets that are affected and making a wallet backup,
then install a new fresh wallet, then import the private key(s) into the new wallet.
All the transactoins associated with those keys (= CGA addresses) are now read from the official block chain, so anything that
happened on the fork will never show up in the wallet and the sending wallet should have the balance again that was sent on the fork.
Hope this helps!

I sent the CGA from my inceptioncraft pool account to my CGA wallet. Ive redownloaded the block chain am on running the most up to date CGA wallet and have even sent coins from other pools to my wallet and had them confirmed.

The coins in my inceptioncraft pool account have all confirmed except the last payout which was probably mined on the forked block chain which is fine its only like .07cga. But the rest is confirmed and has not been received in my CGA wallet after making the payout request.

There is no transaction of the coins being sent to my wallet from inceptioncraft in my wallet nor inceptioncraft transaction records.

Its like inceptioncraft just never sent them to me.

My apologies, the coins are all there but the payout scripts do not appear to be working. Here's my getinfo from the pool wallet, to prove I didn't run away with them:

{
    "version" : 1030002,
    "protocolversion" : 70003,
    "walletversion" : 60000,
    "balance" : 79.57981508,
    "blocks" : 64183,
    "timeoffset" : -2,
    "connections" : 63,
    "proxy" : "",
    "difficulty" : 2.03032485,
    "testnet" : false,
    "keypoololdest" : 1391719795,
    "keypoolsize" : 102,
    "paytxfee" : 0.00000000,
    "mininput" : 0.00001000,
    "errors" : ""
}


I will try to get the coins to you tonight, but I have a fever of 100.4 F right now and will probably be going to sleep soon. otherwise, I'll fix it tomorrow.
hoosen
Member
**
Offline Offline

Activity: 89


View Profile
March 19, 2014, 12:01:11 AM
 #2165

Well at least that is sorted was trippin about those coins the past few days.

Get well soon my friend.

MUE:7Qt2Tue6RcWCA2GJhWHehS5783D62MSB2S
Cor2
Hero Member
*****
Offline Offline

Activity: 595


View Profile
March 19, 2014, 12:26:46 AM
 #2166

The block finding time is now 60 sec (30 blocks found in 30 mins from block 64115 to 64145) so still not near the designed 40 sec.
The diff seems not to jump as high as before any more, but apparently still enough to cause some blocks to take several minutes to be found, slowing the average down quite a bit.
This will continue until the network hash gets a bit higher. Like I said before we had Kimotos Gravity Well before but there are exploits that involve nTime, until someone comes up with a better solution, the only thing that will stabilize the block time is more people mining. So spread the word!
OK, I had the impression that the mining activity had already risen quite a bit, the pool I am on had mostly myself as contributor a couple days ago while this morning it had increased to more than 10% of the Network hashing rate (around 30Mh/s of almost 300Mh/s) so my contribution had shrunk to barely over 1% of the pool. I thought that to be a decent hash rate.
Also, my understanding is that as long as the network hashing rate is constant, the diff does not change as jumps are mostly caused by changes in network hashing rate - which is a result of a profit switching pool... Without them, diff should be relatively constant unless it is very sensitive to block finding rate, which is a statistical and therefor noisy process by definition
Now that almost all blocks carry around 0.3 CGA reward, there is no reason for pools to switch and I'd expected the block finding rate and the diff to stabilize.
I see still large difference between actual block finding rate and design - for example the 40 blocks period from 64132 to 64172 took over an hour, so that is more than 1.5 minutes per block average, while the design is 40 sec. I didn't check the diff of the intermediate blocks but I am surprised that the finding time is more than 2x the designed value.
I am not complaining, just pointing to possible areas to focus on in a next release - we'll have to accept that the mining will generate
much less coins than we'd expect based on calculation - the payout should already be more smooth than before.

SYNC: Sd3XBRmhrrr39Wj4rtjb3YAkwWvCze44BZ                    ORB: odyWi677JDQy7Gc6Nv6kCdnajmScqgTkDE       Honest pools (payout matching calculation):
TransferWise: International money transfer for 1%fee        Doge to the moon! D9FGY7Bhwbj2jrnk7v8VR47HTu7vfVu1gV         Nut2pools and Steadymining
s4w3d0ff
Sr. Member
****
Offline Offline

Activity: 322


Spray and Pray


View Profile
March 19, 2014, 12:53:46 AM
 #2167

The block finding time is now 60 sec (30 blocks found in 30 mins from block 64115 to 64145) so still not near the designed 40 sec.
The diff seems not to jump as high as before any more, but apparently still enough to cause some blocks to take several minutes to be found, slowing the average down quite a bit.
This will continue until the network hash gets a bit higher. Like I said before we had Kimotos Gravity Well before but there are exploits that involve nTime, until someone comes up with a better solution, the only thing that will stabilize the block time is more people mining. So spread the word!
OK, I had the impression that the mining activity had already risen quite a bit, the pool I am on had mostly myself as contributor a couple days ago while this morning it had increased to more than 10% of the Network hashing rate (around 30Mh/s of almost 300Mh/s) so my contribution had shrunk to barely over 1% of the pool. I thought that to be a decent hash rate.
Also, my understanding is that as long as the network hashing rate is constant, the diff does not change as jumps are mostly caused by changes in network hashing rate - which is a result of a profit switching pool... Without them, diff should be relatively constant unless it is very sensitive to block finding rate, which is a statistical and therefor noisy process by definition
Now that almost all blocks carry around 0.3 CGA reward, there is no reason for pools to switch and I'd expected the block finding rate and the diff to stabilize.
I see still large difference between actual block finding rate and design - for example the 40 blocks period from 64132 to 64172 took over an hour, so that is more than 1.5 minutes per block average, while the design is 40 sec. I didn't check the diff of the intermediate blocks but I am surprised that the finding time is more than 2x the designed value.
I am not complaining, just pointing to possible areas to focus on in a next release - we'll have to accept that the mining will generate
much less coins than we'd expect based on calculation - the payout should already be more smooth than before.

To be honest the difficulty is more of less random. Even with a stable network hash rate you could find 2 blocks back to back in under 10 secs if very lucky. Since the re-target rate is so short the diff will make big jumps.The diff changes due to the time between blocks. So while one block was solved in 1 min and the next in 10 sec then the diff will do significant jumps. Where are you seeing the nethashrate being around 300Mhash? I haven't seen it go above 200Mhash in the last week or so.

BTC:15D8VaZco22GTLVrFMAehXyif6EGf8GMYV
|⚒|Cryptographic Anomaly|⚒|
Cor2
Hero Member
*****
Offline Offline

Activity: 595


View Profile
March 19, 2014, 01:40:40 AM
 #2168

To be honest the difficulty is more of less random. Even with a stable network hash rate you could find 2 blocks back to back in under 10 secs if very lucky. Since the re-target rate is so short the diff will make big jumps.The diff changes due to the time between blocks. So while one block was solved in 1 min and the next in 10 sec then the diff will do significant jumps. Where are you seeing the nethashrate being around 300Mhash? I haven't seen it go above 200Mhash in the last week or so.
Now that I think about it longer, it may have been that I saw a network hash rate of 210 or 220Mh/s with the pool doing over 25Mh/s.

So you are confirming that the diff calculation is very sensitive to the last block finding time, which is a random process of luck, so that as a result the diff will jump around and the block finding time might increase or decrease, but since the max decrease is 40 sec below designed (40 sec) while the maximum increase is extremely large (minutes or hours), the result of jumping diff is a much higher average block finding time, since (for example) at a standard diff of 3 a block may suddenly be found after 5 seconds so in 1/8 of designed time, which could lead the re-target algorithm to simply (erroneously) multiply the diff by 8 in an attempt to get the next block find time 8 times 5s.
However, since the diff of 3 was actually giving an avg 40s block finding time and it was luck that a block was found after 5s, the new diff of 3x8 = 24 will result in an average block finding time of 8x40s = 5 min 20s. Hence, the upward correction of diff should be dampened to avoid these overshoots, since a higher diff causes much more time increase than lower diffs causes time decrease.
Since a switching pool that turns on and off on a per-block basis cannot be prevented with a diff that is calculated before the block starts, there is no reason to make a very aggressive "attack" (increase) of diff that will just hurt all steady miners by a much higher block finding time. So, it is better to dampen the diff to respond reasonable fast to sudden hash rate changes (within a couple retargets) but there is no need to re-target to a completely new value every time. For example, the diff could be limited to change no more than doubling or halving during retarget, which will still allow a very large change in a few steps, but not the large jumps we have seen. If the concern is to quickly recover from a major drop in network hash rate, then the re-target algorithm could make an exception for a long time since last block found to re-target fresh immediately, while when block are found regularly to use a more smooth re-target. Reducing jumps will allow the avg block find time to be closed to the designed 40s time.

SYNC: Sd3XBRmhrrr39Wj4rtjb3YAkwWvCze44BZ                    ORB: odyWi677JDQy7Gc6Nv6kCdnajmScqgTkDE       Honest pools (payout matching calculation):
TransferWise: International money transfer for 1%fee        Doge to the moon! D9FGY7Bhwbj2jrnk7v8VR47HTu7vfVu1gV         Nut2pools and Steadymining
s4w3d0ff
Sr. Member
****
Offline Offline

Activity: 322


Spray and Pray


View Profile
March 19, 2014, 03:44:53 AM
 #2169

To be honest the difficulty is more of less random. Even with a stable network hash rate you could find 2 blocks back to back in under 10 secs if very lucky. Since the re-target rate is so short the diff will make big jumps.The diff changes due to the time between blocks. So while one block was solved in 1 min and the next in 10 sec then the diff will do significant jumps. Where are you seeing the nethashrate being around 300Mhash? I haven't seen it go above 200Mhash in the last week or so.
Now that I think about it longer, it may have been that I saw a network hash rate of 210 or 220Mh/s with the pool doing over 25Mh/s.

So you are confirming that the diff calculation is very sensitive to the last block finding time, which is a random process of luck, so that as a result the diff will jump around and the block finding time might increase or decrease, but since the max decrease is 40 sec below designed (40 sec) while the maximum increase is extremely large (minutes or hours), the result of jumping diff is a much higher average block finding time, since (for example) at a standard diff of 3 a block may suddenly be found after 5 seconds so in 1/8 of designed time, which could lead the re-target algorithm to simply (erroneously) multiply the diff by 8 in an attempt to get the next block find time 8 times 5s.
However, since the diff of 3 was actually giving an avg 40s block finding time and it was luck that a block was found after 5s, the new diff of 3x8 = 24 will result in an average block finding time of 8x40s = 5 min 20s. Hence, the upward correction of diff should be dampened to avoid these overshoots, since a higher diff causes much more time increase than lower diffs causes time decrease.
Since a switching pool that turns on and off on a per-block basis cannot be prevented with a diff that is calculated before the block starts, there is no reason to make a very aggressive "attack" (increase) of diff that will just hurt all steady miners by a much higher block finding time. So, it is better to dampen the diff to respond reasonable fast to sudden hash rate changes (within a couple retargets) but there is no need to re-target to a completely new value every time. For example, the diff could be limited to change no more than doubling or halving during retarget, which will still allow a very large change in a few steps, but not the large jumps we have seen. If the concern is to quickly recover from a major drop in network hash rate, then the re-target algorithm could make an exception for a long time since last block found to re-target fresh immediately, while when block are found regularly to use a more smooth re-target. Reducing jumps will allow the avg block find time to be closed to the designed 40s time.

That is what Kimotos Gravity Well did/does... but have yet to figure out a better solution.

BTC:15D8VaZco22GTLVrFMAehXyif6EGf8GMYV
|⚒|Cryptographic Anomaly|⚒|
brother3
Hero Member
*****
Offline Offline

Activity: 602



View Profile
March 19, 2014, 06:09:30 AM
 #2170

Ok you two....Stop speaking Korean!!!

I don't understand a damn thing...However, would you both kindly look at this post for a possible KGW-like solution?

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

 Grin


To be honest the difficulty is more of less random. Even with a stable network hash rate you could find 2 blocks back to back in under 10 secs if very lucky. Since the re-target rate is so short the diff will make big jumps.The diff changes due to the time between blocks. So while one block was solved in 1 min and the next in 10 sec then the diff will do significant jumps. Where are you seeing the nethashrate being around 300Mhash? I haven't seen it go above 200Mhash in the last week or so.
Now that I think about it longer, it may have been that I saw a network hash rate of 210 or 220Mh/s with the pool doing over 25Mh/s.

So you are confirming that the diff calculation is very sensitive to the last block finding time, which is a random process of luck, so that as a result the diff will jump around and the block finding time might increase or decrease, but since the max decrease is 40 sec below designed (40 sec) while the maximum increase is extremely large (minutes or hours), the result of jumping diff is a much higher average block finding time, since (for example) at a standard diff of 3 a block may suddenly be found after 5 seconds so in 1/8 of designed time, which could lead the re-target algorithm to simply (erroneously) multiply the diff by 8 in an attempt to get the next block find time 8 times 5s.
However, since the diff of 3 was actually giving an avg 40s block finding time and it was luck that a block was found after 5s, the new diff of 3x8 = 24 will result in an average block finding time of 8x40s = 5 min 20s. Hence, the upward correction of diff should be dampened to avoid these overshoots, since a higher diff causes much more time increase than lower diffs causes time decrease.
Since a switching pool that turns on and off on a per-block basis cannot be prevented with a diff that is calculated before the block starts, there is no reason to make a very aggressive "attack" (increase) of diff that will just hurt all steady miners by a much higher block finding time. So, it is better to dampen the diff to respond reasonable fast to sudden hash rate changes (within a couple retargets) but there is no need to re-target to a completely new value every time. For example, the diff could be limited to change no more than doubling or halving during retarget, which will still allow a very large change in a few steps, but not the large jumps we have seen. If the concern is to quickly recover from a major drop in network hash rate, then the re-target algorithm could make an exception for a long time since last block found to re-target fresh immediately, while when block are found regularly to use a more smooth re-target. Reducing jumps will allow the avg block find time to be closed to the designed 40s time.

That is what Kimotos Gravity Well did/does... but have yet to figure out a better solution.

VICI!
omwtothemoon
Jr. Member
*
Offline Offline

Activity: 50


View Profile
March 19, 2014, 09:12:46 AM
 #2171

Ok you two....Stop speaking Korean!!!

I don't understand a damn thing...However, would you both kindly look at this post for a possible KGW-like solution?

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

 Grin


To be honest the difficulty is more of less random. Even with a stable network hash rate you could find 2 blocks back to back in under 10 secs if very lucky. Since the re-target rate is so short the diff will make big jumps.The diff changes due to the time between blocks. So while one block was solved in 1 min and the next in 10 sec then the diff will do significant jumps. Where are you seeing the nethashrate being around 300Mhash? I haven't seen it go above 200Mhash in the last week or so.
Now that I think about it longer, it may have been that I saw a network hash rate of 210 or 220Mh/s with the pool doing over 25Mh/s.

So you are confirming that the diff calculation is very sensitive to the last block finding time, which is a random process of luck, so that as a result the diff will jump around and the block finding time might increase or decrease, but since the max decrease is 40 sec below designed (40 sec) while the maximum increase is extremely large (minutes or hours), the result of jumping diff is a much higher average block finding time, since (for example) at a standard diff of 3 a block may suddenly be found after 5 seconds so in 1/8 of designed time, which could lead the re-target algorithm to simply (erroneously) multiply the diff by 8 in an attempt to get the next block find time 8 times 5s.
However, since the diff of 3 was actually giving an avg 40s block finding time and it was luck that a block was found after 5s, the new diff of 3x8 = 24 will result in an average block finding time of 8x40s = 5 min 20s. Hence, the upward correction of diff should be dampened to avoid these overshoots, since a higher diff causes much more time increase than lower diffs causes time decrease.
Since a switching pool that turns on and off on a per-block basis cannot be prevented with a diff that is calculated before the block starts, there is no reason to make a very aggressive "attack" (increase) of diff that will just hurt all steady miners by a much higher block finding time. So, it is better to dampen the diff to respond reasonable fast to sudden hash rate changes (within a couple retargets) but there is no need to re-target to a completely new value every time. For example, the diff could be limited to change no more than doubling or halving during retarget, which will still allow a very large change in a few steps, but not the large jumps we have seen. If the concern is to quickly recover from a major drop in network hash rate, then the re-target algorithm could make an exception for a long time since last block found to re-target fresh immediately, while when block are found regularly to use a more smooth re-target. Reducing jumps will allow the avg block find time to be closed to the designed 40s time.

That is what Kimotos Gravity Well did/does... but have yet to figure out a better solution.
+1 for bringing that up! I have no idea what it says however lol:p
Miner538
Jr. Member
*
Offline Offline

Activity: 43


Destined to be great


View Profile WWW
March 19, 2014, 10:35:44 AM
 #2172

I am mining this coin for a while and I am happy to see the rewards being payout more often.

This will attract more miners along the way. DEV your the best!

+1 for all the effort

1ANbJxTmuWoA7bm4yuUMA4MvPh2qhazMHu
In need of a BTC Miner ?
https://www.kncminer.com/?resellerid=607
VarDiff
Full Member
***
Offline Offline

Activity: 154


Bounty hunter


View Profile
March 19, 2014, 11:03:27 AM
 #2173



Cryptographic Anomaly added to altcoins database
Good luck, miners

tertius993
Hero Member
*****
Offline Offline

Activity: 667


View Profile
March 19, 2014, 11:06:06 AM
 #2174

I notice the exchanges still have the old logo - have they been asked to change?
kwisatz
Jr. Member
*
Offline Offline

Activity: 52


View Profile
March 19, 2014, 11:17:18 AM
 #2175

Speaking of exchanges, there is a new poll about the next coins to be added at Bittrex: https://bitcointalk.org/index.php?topic=521726.0

BTC: 1KW5QKJ1sNt6cM5XrvqGjdQkWHB7msN1t8
LTC: LbpiDBCU8ygfmAzktarCFd96uiQR8dChhn
CGA: AKJKoPfQYtoP3iBngtACusbJQXxoQc4rUf
brother3
Hero Member
*****
Offline Offline

Activity: 602



View Profile
March 19, 2014, 03:05:19 PM
 #2176

Speaking of exchanges, there is a new poll about the next coins to be added at Bittrex: https://bitcointalk.org/index.php?topic=521726.0

Voted... We are # 2 right now

VICI!
s4w3d0ff
Sr. Member
****
Offline Offline

Activity: 322


Spray and Pray


View Profile
March 19, 2014, 06:03:44 PM
 #2177

Ok you two....Stop speaking Korean!!!

I don't understand a damn thing...However, would you both kindly look at this post for a possible KGW-like solution?

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

 Grin

Nice find! Unfortunately the proposed fix can still be exploited to a "time traveling attack". They seem to be working it out in that thread so I will keep my eyes on it.  Wink

BTC:15D8VaZco22GTLVrFMAehXyif6EGf8GMYV
|⚒|Cryptographic Anomaly|⚒|
s4w3d0ff
Sr. Member
****
Offline Offline

Activity: 322


Spray and Pray


View Profile
March 19, 2014, 06:06:09 PM
 #2178

I notice the exchanges still have the old logo - have they been asked to change?

Not yet. I will be sending emails today.

BTC:15D8VaZco22GTLVrFMAehXyif6EGf8GMYV
|⚒|Cryptographic Anomaly|⚒|
cdboot
Full Member
***
Offline Offline

Activity: 182


View Profile
March 19, 2014, 06:12:15 PM
 #2179

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

BTC38.com

CGA go go
s4w3d0ff
Sr. Member
****
Offline Offline

Activity: 322


Spray and Pray


View Profile
March 19, 2014, 06:13:19 PM
 #2180

Cryptographic Anomaly added to altcoins database
Good luck, miners

Awesome! thank you! Trying to figure out where to put this link... I guess make a Coin Database section...

BTC:15D8VaZco22GTLVrFMAehXyif6EGf8GMYV
|⚒|Cryptographic Anomaly|⚒|
Pages: « 1 ... 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 [109] 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!