s4w3d0ff (OP)
Sr. Member
Offline
Activity: 322
Merit: 250
Spray and Pray
|
|
February 27, 2014, 08:50:08 PM |
|
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?
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)
|
|
|
|
phzi
|
|
February 27, 2014, 10:18:01 PM |
|
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).
|
|
|
|
phzi
|
|
February 27, 2014, 10:23:01 PM |
|
I have an insane idea.... why dont we just broadcast the block reward as 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 ... You can't change a blockhash... ? That would involve mining another block. 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).
|
|
|
|
Taint
Member
Offline
Activity: 60
Merit: 10
|
|
February 27, 2014, 11:00:45 PM |
|
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
|
|
|
|
phzi
|
|
February 27, 2014, 11:23:51 PM |
|
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... 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.
|
|
|
|
kwisatz
Newbie
Offline
Activity: 52
Merit: 0
|
|
February 28, 2014, 01:23:38 AM |
|
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: 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 |
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.
|
|
|
|
s4w3d0ff (OP)
Sr. Member
Offline
Activity: 322
Merit: 250
Spray and Pray
|
|
February 28, 2014, 01:57:20 AM |
|
Version 1.1.2.3 Update is going on March 1st @ Noon PST
|
|
|
|
JouleBurner
Newbie
Offline
Activity: 10
Merit: 0
|
|
February 28, 2014, 02:20:28 AM |
|
Well, this is rather interesting
|
|
|
|
tf2honeybadger
|
|
February 28, 2014, 02:21:52 AM |
|
Version 1.1.2.3 Update is going on March 1st @ Noon PST You should make it be 1.2.1.1, probably. The final digit is reserved for the build number, and this is a fairly significant change. 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.
|
|
|
|
|
arielbit
Legendary
Offline
Activity: 3416
Merit: 1059
|
|
February 28, 2014, 03:36:10 AM |
|
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!
|
|
|
|
s4w3d0ff (OP)
Sr. Member
Offline
Activity: 322
Merit: 250
Spray and Pray
|
|
February 28, 2014, 04:19:00 AM |
|
Version 1.1.2.3 Update is going on March 1st @ Noon PST You should make it be 1.2.1.1, probably. The final digit is reserved for the build number, and this is a fairly significant change. 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.
|
|
|
|
MrE78
|
|
February 28, 2014, 04:35:53 AM |
|
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.
|
Like CEX.IO but better SCRYPT.CC Scrypt based cloud hashing PM for script for auto reinvest
|
|
|
s4w3d0ff (OP)
Sr. Member
Offline
Activity: 322
Merit: 250
Spray and Pray
|
|
February 28, 2014, 06:15:58 AM |
|
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. I like it (besides the ridiculously high USD/BTC fee) but you got to make money somehow.
|
|
|
|
phzi
|
|
February 28, 2014, 06:56:49 AM |
|
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.
|
|
|
|
s4w3d0ff (OP)
Sr. Member
Offline
Activity: 322
Merit: 250
Spray and Pray
|
|
February 28, 2014, 07:21:21 AM |
|
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.
|
|
|
|
Taint
Member
Offline
Activity: 60
Merit: 10
|
|
February 28, 2014, 07:59:54 AM |
|
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... 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. my apologies, to clarify, I was suggesting that you 'snapshot' the net hash rate at the point of the block hash creation, not a continuously changing value. I.e. you wouldn't know what the block hash would be prior to the creation. this would obfuscate the value of the block until it was announced prior to mining.
|
|
|
|
omwtothemoon
Newbie
Offline
Activity: 50
Merit: 0
|
|
February 28, 2014, 08:19:33 AM |
|
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. +1! Looking forward to the update
|
|
|
|
wzttide
|
|
February 28, 2014, 11:24:04 AM |
|
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. +1! Looking forward to the update +1 I think a coin does not need to be technically superior to other coins. The concept as a whole needs to be consistent. I'm much more worried about marketing than technical stuff.
|
|
|
|
mxq
Newbie
Offline
Activity: 48
Merit: 0
|
|
February 28, 2014, 12:22:57 PM |
|
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. +1! Looking forward to the update +1 I think a coin does not need to be technically superior to other coins. The concept as a whole needs to be consistent. I'm much more worried about marketing than technical stuff. +1
|
|
|
|
|