I look forward to seeing what this new version of CGA will bring. I have serious reservations about the future of this coin, but will hold my comments until new source is released. I do wish CGA the best future, but it needs more then a simple/pathetic modification of GetBlockValue if it is going to survive for any length of time.
I appreciate your "input", and you are right, I don't have the necessary coding skills to completely rewrite the bitcoin/litecoin protocol, what I can do is "try" to resist the (well known) attacks that you mentioned by removing the gravity well and changing the block reward. Once you find the audacity to create your own coin with your "superior" protocol let me know. 
Topic: âš’[CGA] Cryptographic Anomaly - The Elusive Coinâš’ - page 70. (Read 226295 times)
I look forward to seeing what this new version of CGA will bring. I have serious reservations about the future of this coin, but will hold my comments until new source is released. I do wish CGA the best future, but it needs more then a simple/pathetic modification of GetBlockValue if it is going to survive for any length of time.
Give this place a try ATOMIC-TRADE they even have shares that pay out every 6 hours, free money is always nice
And while your are at it go over to this thread VOTE FOR CGA
Don't miss you chance to get CGA on a new and upcoming exchange.
*disclaimer I do not work nor am I affiliated with ATOMIC-TRADE I just think it is a great exchange that is as fast, sometimes faster then mcxnow.
And while your are at it go over to this thread VOTE FOR CGA
Don't miss you chance to get CGA on a new and upcoming exchange.
*disclaimer I do not work nor am I affiliated with ATOMIC-TRADE I just think it is a great exchange that is as fast, sometimes faster then mcxnow.
I like it (besides the ridiculously high USD/BTC fee) but you got to make money somehow.
Give this place a try ATOMIC-TRADE they even have shares that pay out every 6 hours, free money is always nice
And while your are at it go over to this thread VOTE FOR CGA
Don't miss you chance to get CGA on a new and upcoming exchange.
*disclaimer I do not work nor am I affiliated with ATOMIC-TRADE I just think it is a great exchange that is as fast, sometimes faster then mcxnow.
And while your are at it go over to this thread VOTE FOR CGA
Don't miss you chance to get CGA on a new and upcoming exchange.
*disclaimer I do not work nor am I affiliated with ATOMIC-TRADE I just think it is a great exchange that is as fast, sometimes faster then mcxnow.
Version 1.1.2.3 Update is going on March 1st @ Noon PST
From clientversion.h:
#define CLIENT_VERSION_MAJOR 1
#define CLIENT_VERSION_MINOR 1
#define CLIENT_VERSION_REVISION 2
#define CLIENT_VERSION_BUILD 2
Of course, you can do whatever you want, but strictly speaking, the proper way would be 1.2.1.1.
Ehh your right.
Can't we just leave it like it is and start our own CGA insider multipool that mines all the good CGA blocks and switches to wafflepool or something for the other blocks, then just don't tell anybody on the original post about the multipool so they mine the zero reward blocks.
best coin and idea ever if such exists!
Be sure to vote for CGA!! Decide on the next coin to be offered at Atomic-Trade.com
https://bitcointalksearch.org/topic/m.5418475
https://bitcointalksearch.org/topic/m.5418475
Version 1.1.2.3 Update is going on March 1st @ Noon PST
From clientversion.h:
#define CLIENT_VERSION_MAJOR 1
#define CLIENT_VERSION_MINOR 1
#define CLIENT_VERSION_REVISION 2
#define CLIENT_VERSION_BUILD 2
Of course, you can do whatever you want, but strictly speaking, the proper way would be 1.2.1.1.
Well, this is rather interesting
Version 1.1.2.3 Update is going on March 1st @ Noon PST
How about if the the bonus block is kept, but instead of having a full coin, it is X times more than usual block and the rest of the coin is dispersed over the other blocks.
For instance, if the bonus block is 4 times bigger, then it would be 1/(diff+3)*4, while the other blocks - 1/(diff+3). It would look something like this:
It will still be one coin every N blocks (where N=diff). At higher difficulties, a usual block with more transactions may be more valuable than a bonus one.
For instance, if the bonus block is 4 times bigger, then it would be 1/(diff+3)*4, while the other blocks - 1/(diff+3). It would look something like this:
| Diff | Bonus block | Usual bock |
| 4 | 0,571428571 | 0,142857143 |
| 6 | 0,444444444 | 0,111111111 |
| 8 | 0,363636364 | 0,090909091 |
| 16 | 0,210526316 | 0,052631579 |
| 32 | 0,114285714 | 0,028571429 |
I have no idea if this would work, but how about this?
Rather than the anomaly being created based on 1/Difficulty, how about the reward being determined by 1/Network hash rate at declaration of block reward?
You could then trigger the reward based on another factor, such as the last digit being odd, even, the number '3', etc.
The network hash fluctuates rapidly, unlike difficulty. The reward would still be announced at the start of the block, but as it could not be so easily predicted, the Multi-pools would not have as much time to 'swoop in' and steal the block. Similarly, as you can't accurately control the total net Hash rate, you couldn't force it to generate an Anomaly every time.
-T
The block reward is part of the block hash - so you can't use something that fluctuates like crazy...Rather than the anomaly being created based on 1/Difficulty, how about the reward being determined by 1/Network hash rate at declaration of block reward?
You could then trigger the reward based on another factor, such as the last digit being odd, even, the number '3', etc.
The network hash fluctuates rapidly, unlike difficulty. The reward would still be announced at the start of the block, but as it could not be so easily predicted, the Multi-pools would not have as much time to 'swoop in' and steal the block. Similarly, as you can't accurately control the total net Hash rate, you couldn't force it to generate an Anomaly every time.
-T
When you are mining, you are performing a hash on a concatenation of:
Version # (Block version number)
hashPrevBlock (Hash of the previous block header)
hashMerkleRoot (hash of the transactions to be included in the block)
nTime (Current timestamp)
Bits (target [aka difficulty])
nonce (A number you increment or choose randomly)
The reason I am showing this, is that hashMerkleRoot is part of what you are hashing.
hashMerkleRoot is essentially a summary of all of the transactions to be included in the block - the first transaction always being a tx that says "pay me". You MUST know how much you are going to get paid.
If you used nethashrate, the hashMerkleRoot would have to change constantly, and this is simply not possible - miners can't constantly change what they are hashing on... even nTime is only updated every few seconds.
I have no idea if this would work, but how about this?
Rather than the anomaly being created based on 1/Difficulty, how about the reward being determined by 1/Network hash rate at declaration of block reward?
You could then trigger the reward based on another factor, such as the last digit being odd, even, the number '3', etc.
The network hash fluctuates rapidly, unlike difficulty. The reward would still be announced at the start of the block, but as it could not be so easily predicted, the Multi-pools would not have as much time to 'swoop in' and steal the block. Similarly, as you can't accurately control the total net Hash rate, you couldn't force it to generate an Anomaly every time.
-T
Rather than the anomaly being created based on 1/Difficulty, how about the reward being determined by 1/Network hash rate at declaration of block reward?
You could then trigger the reward based on another factor, such as the last digit being odd, even, the number '3', etc.
The network hash fluctuates rapidly, unlike difficulty. The reward would still be announced at the start of the block, but as it could not be so easily predicted, the Multi-pools would not have as much time to 'swoop in' and steal the block. Similarly, as you can't accurately control the total net Hash rate, you couldn't force it to generate an Anomaly every time.
-T
I have an insane idea.... why dont we just broadcast the block reward as
so was could just declare the value of the block to be x or 0, then after the block begins we update the block hash to reflect the true value ...
You can't change a blockhash... ? That would involve mining another block.Code:
notfound(slice rewardValAfterBlockStarts() )
so was could just declare the value of the block to be x or 0, then after the block begins we update the block hash to reflect the true value ...
I have no idea what that pseudo-code is supposed to be. But the proper solution would be:
1. each block starts with 2 tx instead of 1
2. the first tx pays the miner a very small reward (maybe .01 in this case)
3. the second tx pays the out address of the first tx in the last block a variable reward (0 or 1 based on the HASH of the last block)
I have a feeling, however, this development is beyond the capabilities of the CGA developer, specifically seeing as he didn't even understand his own simple modifications well enough to realize that block reward was determined before the block was discovered and not after (which should be extremely obvious to anyone that knows the bitcoin protocol).
The difference is the amount of coins going into circulation directly reflects the difficulty. No other coin (that I know of) does this. Yes the difficulty does determine how much the individual miner may receive but the amount of coins being generated is all ways the same.
Other then PPCoin and Novacoin (which both decrease block reward with diff decreases)?Wow, writing the above made me think... What if someone made a coin that changed the block time depending on the difficulty? Say making the block time longer if the difficulty went up. (blowing my own mind right now)
Block time meaning target time to block? As in, effective difficulty would just be a factor of the real difficulty?---
Getting rid of KGW fixes the re-org and block reward manipulation attack. It also leaves the coin open to huge diff swings (not that KGW fixes this entirely - just look at luckycoin's recent situation), which is a pretty big problem unto itself.
Changing the block reward scheme destroys the novelty of this coin, in my opinion.
At this point, I don't honestly see a solution that will see this coin survive the year that doesn't involve re-writing the block reward scheme and protocol to issue rewards in the next block (which would be truly novel and awesome).
I'm a truly hopeless coder so may be misreading the code, but doesn't your change simply vary the reward with the difficulty? I.e higher difficulty means a lower reward?
Surely that is exactly what every other coin does? Albeit by making solving the block harder.
Could it not vary more irregularly with the remainder as before but still reward "something" in every block?
Surely that is exactly what every other coin does? Albeit by making solving the block harder.
Could it not vary more irregularly with the remainder as before but still reward "something" in every block?
The difference is the amount of coins going into circulation directly reflects the difficulty. No other coin (that I know of) does this. Yes the difficulty does determine how much the individual miner may receive but the amount of coins being generated is all ways the same.
Wow, writing the above made me think... What if someone made a coin that changed the block time depending on the difficulty? Say making the block time longer if the difficulty went up. (blowing my own mind right now)
Completely removing KMG would get rid of nTime which would solve it right?
This would just solve the reorg attack problem, but you can still know what the block is worth before mining (this is a problem all coins have).Two things: First: Yes, removing the bonus blocks would prevent the multipool problem, but it would also remove one of the main reasons this coin is attractive. If cryptographic anomalies are no longer a real thing, all the mystique behind the coin would disappear. It's a brand new system and, really, not a lot of people know how it works; when something knew comes along, a lot of people want to know how it works, so they either come here or go to the website to find out, and by then, they're already far more involved in CGA than they are with most of the other coins, and because of this, these curious people are significantly more likely to become loyal miners and investors. It's the reason I'm here. If we lost this feature, CGA wouldn't attract nearly as many curious people to it as it would have, we would be losing a great deal of our ability to grow, and I don't think the multipool issue is likely enough to risk this. I think we should still reward 1/diff for non-bonus blocks, but I don't think that it would be wise, especially early on like this, to remove the bonus blocks altogether.
Second: Sorry if this comes off like nitpicking, because I don't know how likely or possible this is, but, looking at the code you posted, if the difficulty is exactly 3, every client on the network is going to run into an exception, which would be disastrous. Just change either "if(diff < 3)" or "else if(diff > 3)" to "if(diff <= 3)" or "else if(diff >= 3)". I only know python (and g-code, if that counts- I used to program CNC machines), so I don't know if C++ just handles this automatically- sorry if it does.
Second: Sorry if this comes off like nitpicking, because I don't know how likely or possible this is, but, looking at the code you posted, if the difficulty is exactly 3, every client on the network is going to run into an exception, which would be disastrous. Just change either "if(diff < 3)" or "else if(diff > 3)" to "if(diff <= 3)" or "else if(diff >= 3)". I only know python (and g-code, if that counts- I used to program CNC machines), so I don't know if C++ just handles this automatically- sorry if it does.
I think you have to keep the bonus blocks, otherwise as awesome person says it becomes just like every other coin. I am worried that this change makes it rather like every other coin anyway ...
Re. The code, I agree for completeness and elegance but isn't diff a FLOAT? So it can never be exactly 3?
You're right awesomeperson, I should (and will) add if(diff <= 3), thanks for the heads up. Yes tertius, it is a float, tho I have seen the diff have only 1 decimal place at times, and so I believe if we were really lucky (unlucky?) it could happen to fall on a whole number.
As for the bonus block, the problem it creates is that a profit switching multipool could (would) wait until a bonus block shows up and jumps in, steals the 1 CGA, then leaves and leaves everyone with a ridiculously high diff. Yes this would possibly make CGA worth more due the scarcity of the coin would increase, but I'm not sure how long it would take for the diff to drop back down with KGW removed, making CGA much less profitable (IMO). Also, the bonus block actually hurts the elusiveness factor (if a multipool doesn't jump in driving the diff up), it puts more CGA into circulation at any given time, thus making us deviate slightly from what was originally planned (CGA coming into being at 1/diff).
As for the new code making it less of an anomaly, I don't think that is true. By definition an anomaly is a "Deviation or departure from the normal or common order, form, or rule. One that is peculiar, irregular, abnormal, or difficult to classify." I think we have that covered.
Also with the new code, the elusive factor is still at play (even at the same rate, 1/diff) so I'm not worried.I'm a truly hopeless coder so may be misreading the code, but doesn't your change simply vary the reward with the difficulty? I.e higher difficulty means a lower reward?
Surely that is exactly what every other coin does? Albeit by making solving the block harder.
Could it not vary more irregularly with the remainder as before but still reward "something" in every block?
I think you have to keep the bonus blocks, otherwise as awesome person says it becomes just like every other coin. I am worried that this change makes it rather like every other coin anyway ...
What's your suggestion?I don't have one I am afraid, indeed I don't think there is an answer. The part of the bitcoin protocol which requires that the reward of every block be known at the time you start mining the block means that the original concept of the coin simply cannot be achieved.
I have an insane idea.... why dont we just broadcast the block reward as
Code:
notfound(slice rewardValAfterBlockStarts() )
so was could just declare the value of the block to be x or 0, then after the block begins we update the block hash to reflect the true value ...
Completely removing KMG would get rid of nTime which would solve it right?
This would just solve the reorg attack problem, but you can still know what the block is worth before mining (this is a problem all coins have).Two things: First: Yes, removing the bonus blocks would prevent the multipool problem, but it would also remove one of the main reasons this coin is attractive. If cryptographic anomalies are no longer a real thing, all the mystique behind the coin would disappear. It's a brand new system and, really, not a lot of people know how it works; when something knew comes along, a lot of people want to know how it works, so they either come here or go to the website to find out, and by then, they're already far more involved in CGA than they are with most of the other coins, and because of this, these curious people are significantly more likely to become loyal miners and investors. It's the reason I'm here. If we lost this feature, CGA wouldn't attract nearly as many curious people to it as it would have, we would be losing a great deal of our ability to grow, and I don't think the multipool issue is likely enough to risk this. I think we should still reward 1/diff for non-bonus blocks, but I don't think that it would be wise, especially early on like this, to remove the bonus blocks altogether.
Second: Sorry if this comes off like nitpicking, because I don't know how likely or possible this is, but, looking at the code you posted, if the difficulty is exactly 3, every client on the network is going to run into an exception, which would be disastrous. Just change either "if(diff < 3)" or "else if(diff > 3)" to "if(diff <= 3)" or "else if(diff >= 3)". I only know python (and g-code, if that counts- I used to program CNC machines), so I don't know if C++ just handles this automatically- sorry if it does.
Second: Sorry if this comes off like nitpicking, because I don't know how likely or possible this is, but, looking at the code you posted, if the difficulty is exactly 3, every client on the network is going to run into an exception, which would be disastrous. Just change either "if(diff < 3)" or "else if(diff > 3)" to "if(diff <= 3)" or "else if(diff >= 3)". I only know python (and g-code, if that counts- I used to program CNC machines), so I don't know if C++ just handles this automatically- sorry if it does.
I think you have to keep the bonus blocks, otherwise as awesome person says it becomes just like every other coin. I am worried that this change makes it rather like every other coin anyway ...
Re. The code, I agree for completeness and elegance but isn't diff a FLOAT? So it can never be exactly 3?
You're right awesomeperson, I should (and will) add if(diff <= 3), thanks for the heads up. Yes tertius, it is a float, tho I have seen the diff have only 1 decimal place at times, and so I believe if we were really lucky (unlucky?) it could happen to fall on a whole number.
As for the bonus block, the problem it creates is that a profit switching multipool could (would) wait until a bonus block shows up and jumps in, steals the 1 CGA, then leaves and leaves everyone with a ridiculously high diff. Yes this would possibly make CGA worth more due the scarcity of the coin would increase, but I'm not sure how long it would take for the diff to drop back down with KGW removed, making CGA much less profitable (IMO). Also, the bonus block actually hurts the elusiveness factor (if a multipool doesn't jump in driving the diff up), it puts more CGA into circulation at any given time, thus making us deviate slightly from what was originally planned (CGA coming into being at 1/diff).
As for the new code making it less of an anomaly, I don't think that is true. By definition an anomaly is a "Deviation or departure from the normal or common order, form, or rule. One that is peculiar, irregular, abnormal, or difficult to classify." I think we have that covered.
Also with the new code, the elusive factor is still at play (even at the same rate, 1/diff) so I'm not worried. I think you have to keep the bonus blocks, otherwise as awesome person says it becomes just like every other coin. I am worried that this change makes it rather like every other coin anyway ...
What's your suggestion?I don't have one I am afraid, indeed I don't think there is an answer. The part of the bitcoin protocol which requires that the reward of every block be known at the time you start mining the block means that the original concept of the coin simply cannot be achieved.
Completely removing KMG would get rid of nTime which would solve it right?
Jump to: