⚒[CGA] Cryptographic Anomaly - The Elusive Coin⚒

[s4w3d0ff]

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]

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]

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 ...

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]

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]

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]

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]

Version 1.1.2.3 Update is going on March 1st @ Noon PST

[JouleBurner]

Well, this is rather interesting

[tf2honeybadger]

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.

[dbt1033]

Be sure to vote for CGA!!  Decide on the next coin to be offered at Atomic-Trade.com

https://bitcointalk.org/index.php?topic=491588.msg5418475#msg5418475

[arielbit]

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]

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]

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.

[s4w3d0ff]

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]

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]

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]

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]

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]

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]

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