Bitcoin Forum
December 17, 2017, 04:56:51 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 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 ... 159 »
  Print  
Author Topic: ⚒[CGA] Cryptographic Anomaly - The Elusive Coin⚒  (Read 224556 times)
awesomeperson451
Newbie
*
Offline Offline

Activity: 28


View Profile
February 24, 2014, 07:12:53 AM
 #1681

The problem, if I'm understanding this correctly, is that there isn't any known good way to figure out which blocks are anomalies or not without making the process predictable or easily exploited. I've got an idea for a new block reward equation that I think avoids being either one of those: Just take the original equation, Height % Difficulty, and replace height with the newly found hash of the block you are determining the reward of. This way, no one knows which blocks will be anomalies until after someone mines a block and it gets accepted by the network, and every client on the network will agree with each other since the network difficulty and the block hash in question are already agreed upon in the first place. And because the scrypt hashing algorithm has been proven to be completely unpredictable, there's no way to ensure that the next block you mine will pay out, and there's no way to exploit the system that is more efficient or profitable than just mining legitimately.

BTC: 1GamwSZQ91eap3XED8u7XQmDPxbjU7xjoR | CGA: AFnYPruQpNqzi4UEquWPmA4vV2xf6gNGa1
1513486611
Hero Member
*
Offline Offline

Posts: 1513486611

View Profile Personal Message (Offline)

Ignore
1513486611
Reply with quote  #2

1513486611
Report to moderator
1513486611
Hero Member
*
Offline Offline

Posts: 1513486611

View Profile Personal Message (Offline)

Ignore
1513486611
Reply with quote  #2

1513486611
Report to moderator
1513486611
Hero Member
*
Offline Offline

Posts: 1513486611

View Profile Personal Message (Offline)

Ignore
1513486611
Reply with quote  #2

1513486611
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
wzttide
Full Member
***
Offline Offline

Activity: 238


View Profile
February 24, 2014, 07:27:03 AM
 #1682

I'd like to suggest a different block reward system: Instead of reward every x block, reward every block, but devide the reward (1) by the diff. If the diff is less than 3, 3 is taken.

Examples:
Diff = 1
Code:
1/3 = 0.333333333
Block Reward: 0.333333333

Diff = 10
Code:
1/10 = 0.1
Block Reward: 0.100000000

Diff = 200
Code:
1/200 = 0.005
Block Reward: 0.005

This would have some advantages:
  • The rewards wouldn't change at all over time.
  • Every block pays (rewarding long-time-miners).
  • If a multi pool hits the coin, the diff raises within 2 blocks, the multi pool wouldn't be able to mine much coins.

Moving to another hash alorithm is not advisable in my opinion because:
  • Scrypt is pretty ASCI resistent, even if there are scrypt ASICs now, they are not comparable to GPUs because of their very low resell value. Scrypt ASICs are not faster than GPUs.
  • Changing the hash algorithm would require a hard fork or a relaunch of a coin. Relaunch would kill every confidence in the creators, changing the algorithm will result in people jumping off because mining would be more difficult (e. g. scrypt-n-factor).
sublok
Jr. Member
*
Offline Offline

Activity: 35


View Profile WWW
February 24, 2014, 07:32:16 AM
 #1683

The problem, if I'm understanding this correctly, is that there isn't any known good way to figure out which blocks are anomalies or not without making the process predictable or easily exploited. I've got an idea for a new block reward equation that I think avoids being either one of those: Just take the original equation, Height % Difficulty, and replace height with the newly found hash of the block you are determining the reward of. This way, no one knows which blocks will be anomalies until after someone mines a block and it gets accepted by the network, and every client on the network will agree with each other since the network difficulty and the block hash in question are already agreed upon in the first place. And because the scrypt hashing algorithm has been proven to be completely unpredictable, there's no way to ensure that the next block you mine will pay out, and there's no way to exploit the system that is more efficient or profitable than just mining legitimately.

Code:
uint256 prevHash = 0;
if(pindex->pprev)
{
prevHash = pindex->pprev->GetBlockHash();
}


int64 static GetBlockValue(int nHeight, int64 nFees, uint256 prevHash)
{
    int64 nSubsidy = 1 * COIN;

    //check value out

Thats in essence what i was getting at with the prevHash

CGA: AQMKRqz2tryYxFrKQ8C17VnTnhEFuL5q7C |
tertius993
Hero Member
*****
Offline Offline

Activity: 668


View Profile
February 24, 2014, 07:38:18 AM
 #1684

Apologies in advance if this is a stupid question. However, there is something about this I don't really understand.

As I understand it the part of the problem is that it is possible to predict when you get to it if a given block will reward with an anomaly (1 coin).  And if a block is not going to give an anomaly then don't bother to mine it?

However, surely every block has to be mined? You can't just say "oh, block 21,234 has no reward, I'll skip that one and mine block 21,235 instead"  Don't you have to wait for block 21,234 to be mined, before you can move onto the next one?

Moreover, the zero reward blocks may also reward with mining/transaction fees *and* they will include transactions that have to be added to the blockchain.

So all the blocks have to be mined in order anyway?  So is it *really* a problem?

I expect I have missed something crucial somewhere, so happy to be corrected ... Wink
phzi
Hero Member
*****
Offline Offline

Activity: 672


View Profile
February 24, 2014, 07:46:10 AM
 #1685

Perhaps taking from lucky coin ??

Code:
uint256 prevHash = 0;
if(pindex->pprev)
{
prevHash = pindex->pprev->GetBlockHash();
}


int64 static GetBlockValue(int nHeight, int64 nFees, uint256 prevHash)
{
    int64 nSubsidy = 1 * COIN;

    //check value out
if(nHeight < XXX)  
    {
        std::string cseed_str = prevHash.ToString().substr(8,7);
const char* cseed = rand(networkhashps) % (diff - rand(diff);
long seed = hex2long(cseed);
int rand = generateMTRandom(rand(networkhashps) % (diff - rand(diff), 100000);
if(rand > xxx && rand < blockHeight)
nSubsidy = 1 * COIN;
    }


wouldnt that be a proof-able solution? I might be missing the GetBlockValue's overall function but from my understanding its only called in 2 or 3 places..


Does luckycoin actually do this?  I don't see how you can possibly use a rand function in GetBlockValue... it would essentially make block rewards unverifiable at up to the miner to choose (and the miner would obviously always choose to pay himself the largest possible value).  My glance at the luckycoin source doesn't show any randomness as part of the GetBlockValue function.  Simply put, GetBlockValue MUST return a verifiable and repeatable value, or else you are breaking the entire system.

However, surely every block has to be mined? You can't just say "oh, block 21,234 has no reward, I'll skip that one and mine block 21,235 instead"  Don't you have to wait for block 21,234 to be mined, before you can move onto the next one?
Yes... this is exactly what smart multi-pools like MC or WP do - mine only the valuable blocks.  And is what they would likely do to this coin if it got big enough.  For most variable rate coins this doesn't matter too much - Doge, Lotto, Leaf, Karma, Kitteh, etc etc - because the "non-valuable" blocks still offer a reward and are worth mining.

Moving to another hash alorithm is not advisable in my opinion because:
  • Scrypt is pretty ASCI resistent, even if there are scrypt ASICs now, they are not comparable to GPUs because of their very low resell value. Scrypt ASICs are not faster than GPUs.
  • Changing the hash algorithm would require a hard fork or a relaunch of a coin. Relaunch would kill every confidence in the creators, changing the algorithm will result in people jumping off because mining would be more difficult (e. g. scrypt-n-factor).
Moving to another algorithm has nothing to do with ASIC resistance.  It has to do with multi-pools and other large scrypt pools and their ability to attack the coin.  Switching to a less used algorithm negates the risk that multi-pools pose should the coin grow much larger.  Essentially, because of this coin's current design, a "51%" re-org attack (which would only require about 30% of the network hashrate due to the use of KGW) at diff>3 would allow an attacker to make EVERY block an anomaly.  Or, even worse, would allow someone to say mine 2 blocks (one of which would always be an anomaly), cause the next block to not be an anomaly, and then resume the attack when the next block will be an anomaly (basically the blockchain would look fairly normal, but only the attack would get paid and everyone else would get nothing but 0s).

And as an aside, you're crazy if you don't think scrypt ASICs are going to have a huge impact on GPU mining this year...  if Alpha-T manages to deliver, you can expect scrypt network hashrates to basically double.  And that's only one company.
awesomeperson451
Newbie
*
Offline Offline

Activity: 28


View Profile
February 24, 2014, 07:55:11 AM
 #1686

The problem, if I'm understanding this correctly, is that there isn't any known good way to figure out which blocks are anomalies or not without making the process predictable or easily exploited. I've got an idea for a new block reward equation that I think avoids being either one of those: Just take the original equation, Height % Difficulty, and replace height with the newly found hash of the block you are determining the reward of. This way, no one knows which blocks will be anomalies until after someone mines a block and it gets accepted by the network, and every client on the network will agree with each other since the network difficulty and the block hash in question are already agreed upon in the first place. And because the scrypt hashing algorithm has been proven to be completely unpredictable, there's no way to ensure that the next block you mine will pay out, and there's no way to exploit the system that is more efficient or profitable than just mining legitimately.

Code:
uint256 prevHash = 0;
if(pindex->pprev)
{
prevHash = pindex->pprev->GetBlockHash();
}


int64 static GetBlockValue(int nHeight, int64 nFees, uint256 prevHash)
{
    int64 nSubsidy = 1 * COIN;

    //check value out

Thats in essence what i was getting at with the prevHash

Aww... I was so excited that I had an idea, I forgot to read everyone else's suggestions. Also, I'm not good at reading C++ and I don't know enough about the existing CGA code to know exactly what the hell you're talking about, so can you tell me if your code is determining the reward before or after the block is hashed? Sorry if that's a stupid question, but that's the only possible problem I can see right now-- if the reward outcome of block 2 is based on the hash of block 1, it's just as easy to predict whether block 2 will pay out as it was before.

BTC: 1GamwSZQ91eap3XED8u7XQmDPxbjU7xjoR | CGA: AFnYPruQpNqzi4UEquWPmA4vV2xf6gNGa1
phzi
Hero Member
*****
Offline Offline

Activity: 672


View Profile
February 24, 2014, 07:58:14 AM
 #1687

Aww... I was so excited that I had an idea, I forgot to read everyone else's suggestions. Also, I'm not good at reading C++ and I don't know enough about the existing CGA code to know exactly what the hell you're talking about, so can you tell me if your code is determining the reward before or after the block is hashed? Sorry if that's a stupid question, but that's the only possible problem I can see right now-- if the reward outcome of block 2 is based on the hash of block 1, it's just as easy to predict whether block 2 will pay out as it was before.
Because of how bitcoin (and all altcoins based on it so far) are designed, you MUST know the block reward BEFORE the block is hashed.  Every variable reward coin so far is predictable (you know the reward before the block is found).
sublok
Jr. Member
*
Offline Offline

Activity: 35


View Profile WWW
February 24, 2014, 08:05:40 AM
 #1688

Aww... I was so excited that I had an idea, I forgot to read everyone else's suggestions. Also, I'm not good at reading C++ and I don't know enough about the existing CGA code to know exactly what the hell you're talking about, so can you tell me if your code is determining the reward before or after the block is hashed? Sorry if that's a stupid question, but that's the only possible problem I can see right now-- if the reward outcome of block 2 is based on the hash of block 1, it's just as easy to predict whether block 2 will pay out as it was before.
Because of how bitcoin (and all altcoins based on it so far) are designed, you MUST know the block reward BEFORE the block is hashed.  Every variable reward coin so far is predictable (you know the reward before the block is found).

Perhaps we could just delay the payout for two blocks? and use a computed random but verifiable value from from previous blocks?

phzi aside from what cant be done do you have any suggestions that would be easy to implement that would work?

CGA: AQMKRqz2tryYxFrKQ8C17VnTnhEFuL5q7C |
phzi
Hero Member
*****
Offline Offline

Activity: 672


View Profile
February 24, 2014, 08:25:57 AM
 #1689

Perhaps we could just delay the payout for two blocks? and use a computed random but verifiable value from from previous blocks?

phzi aside from what cant be done do you have any suggestions that would be easy to implement that would work?
Easy to implement? No...

Delaying the block reward is a lot more complicated then it sounds, and requires some serious modifications to the core code and protocol.  Something like that is more likely to be developed for a new coin, if it ever is. (I have been considering doing this myself for a while... but as tf2 said, I have a day job that keeps me quite occupied).
ralph12
Jr. Member
*
Offline Offline

Activity: 44


View Profile
February 24, 2014, 08:38:07 AM
 #1690

I'll admit I've only skimmed the source code, but I still don't get why this is such a bad thing. Wouldn't lots of coins have this same problem?

CGA: AaYmxXXwuGhkXEYVndAaUPfjUpmG9M7V1a
awesomeperson451
Newbie
*
Offline Offline

Activity: 28


View Profile
February 24, 2014, 08:49:17 AM
 #1691

Aww... I was so excited that I had an idea, I forgot to read everyone else's suggestions. Also, I'm not good at reading C++ and I don't know enough about the existing CGA code to know exactly what the hell you're talking about, so can you tell me if your code is determining the reward before or after the block is hashed? Sorry if that's a stupid question, but that's the only possible problem I can see right now-- if the reward outcome of block 2 is based on the hash of block 1, it's just as easy to predict whether block 2 will pay out as it was before.
Because of how bitcoin (and all altcoins based on it so far) are designed, you MUST know the block reward BEFORE the block is hashed.  Every variable reward coin so far is predictable (you know the reward before the block is found).

That's a major problem then... If the block reward must be known before the block is solved, then any attempt to obfuscate said reward is inherently flawed. Again, I don't know nearly enough about how this works to know if this is possible without coming up with a completely new system, but is it in any way possible to rewrite the code to eliminate that restriction? Because, barring some sort of insanely clever idea, that's the only way we're gonna get rid of this exploit.

BTC: 1GamwSZQ91eap3XED8u7XQmDPxbjU7xjoR | CGA: AFnYPruQpNqzi4UEquWPmA4vV2xf6gNGa1
sublok
Jr. Member
*
Offline Offline

Activity: 35


View Profile WWW
February 24, 2014, 08:51:13 AM
 #1692


Quote

Does luckycoin actually do this?  I don't see how you can possibly use a rand function in GetBlockValue... it would essentially make block rewards unverifiable at up to the miner to choose (and the miner would obviously always choose to pay himself the largest possible value).  My glance at the luckycoin source doesn't show any randomness as part of the GetBlockValue function.  Simply put, GetBlockValue MUST return a verifiable and repeatable value, or else you are breaking the entire system.
 


@phzi it appears that it does use a random assigned int to discern the payout..

Code:
int static generateMTRandom(unsigned int s, int range)
{
random::mt19937 gen(s);
random::uniform_int_distribution<> dist(1, range);
return dist(gen);
}
 
 
int64 static GetBlockValue(int nHeight, int64 nFees, uint256 prevHash)
{
int64 nSubsidy = 88 * COIN;
 
if(nHeight < 50000)
{
const char* cseed = prevHash.ToString().substr(8,7).c_str();
long seed = hex2long(cseed);
 
int rand = generateMTRandom(seed, 100000);
 
if(rand > 30000 && rand < 35001)
nSubsidy = 188 * COIN;
else if(rand > 70000 && rand < 71001)
nSubsidy = 588 * COIN;
else if(rand > 50000 && rand < 50011)
nSubsidy = 5888 * COIN;
}
else
{
// Subsidy is cut in half every 1,036,800 blocks, which will occur approximately every 2 years
nSubsidy >>= (nHeight / 1036800); // Luckycoin: 1036.8K blocks in ~2 years
 
const char* cseed = prevHash.ToString().substr(8,7).c_str();
long seed = hex2long(cseed);
 
int rand = generateMTRandom(seed, 100000);
 
if(rand > 30000 && rand < 35001)
nSubsidy *= 2;
else if(rand > 70000 && rand < 71001)
nSubsidy *= 5;
else if(rand > 50000 && rand < 50011)
nSubsidy *= 58;
}
 
return nSubsidy + nFees;
}

CGA: AQMKRqz2tryYxFrKQ8C17VnTnhEFuL5q7C |
oudekaas
Full Member
***
Offline Offline

Activity: 145


View Profile
February 24, 2014, 09:10:21 AM
 #1693

First of all I think it is outstanding how you guys have been discussing the issues with regards to the found problem. A real example of how it should be done in the crypto society. No BS just get on with it!

There was a fourth option and you didn't even contemplate choosing for that and that was to just let this coin die and not tell anyone. So a lot of respect to you guys and thx again phzi for joining us on irc and helping to brainstorm possible solutions. I believe we got a solid dev team that will go the extra mile to get CGA back on the road!

I am not sure whether I would prefer KGW or not, not enough technical insight. I leave the decision to you guys.

Also I don't mind changing over to the N algorythm as it has advantages and makes us a lot more future proof against the bigger farms/ multipools.

phzi
Hero Member
*****
Offline Offline

Activity: 672


View Profile
February 24, 2014, 09:18:55 AM
 #1694

@phzi it appears that it does use a random assigned int to discern the payout..
No it doesn't ... GenerateMTRandom isn't random... it's a pseudo-random function that when fed the same seed will always produce the same result.
mxq
Jr. Member
*
Offline Offline

Activity: 48


View Profile
February 24, 2014, 09:30:22 AM
 #1695

Current net hashrate is random
tertius993
Hero Member
*****
Offline Offline

Activity: 668


View Profile
February 24, 2014, 10:01:13 AM
 #1696

I too have no issue with changing the algorithm - I really don't think it will create a loss of confidence, quite the reverse it will demonstrate commitment to a long-lived interesting coin.

Regarding KGW, sounds like we should drop it, but I really don't know enough to say - happy either way.
arielbit
Legendary
*
Offline Offline

Activity: 1414


View Profile
February 24, 2014, 10:13:05 AM
 #1697

i'll wait till s4w3d0ff wakes up  Cheesy

good work on CGA geeks out there..

if CGA would achive this = rarity + elusiveness/randomness/anomalous + resistances to commercial farms, ASICs and multipools.....the best coin ever!

arielbit
Legendary
*
Offline Offline

Activity: 1414


View Profile
February 24, 2014, 10:29:25 AM
 #1698

@phzi it appears that it does use a random assigned int to discern the payout..
No it doesn't ... GenerateMTRandom isn't random... it's a pseudo-random function that when fed the same seed will always produce the same result.
how about time added to the equation?time is always changing..
brokedummy
Hero Member
*****
Offline Offline

Activity: 784


View Profile
February 24, 2014, 11:02:46 AM
 #1699

I don't know what you guys are talking about but I'm not selling my CGA. If anybody else needs to panic sell their CGA and they don't see the depth in the book, PM me. This is ridiculous. Still only 15000 something CGA. I don't think there was any need to panic. Now how are you going to buy back in cheaper if nobody else is panicking like a noob?

KNC - KingNcoin - rare, fair, pos only https://yobit.net/en/trade/KNC/BTC
wzttide
Full Member
***
Offline Offline

Activity: 238


View Profile
February 24, 2014, 11:58:38 AM
 #1700

I don't know what you guys are talking about but I'm not selling my CGA. If anybody else needs to panic sell their CGA and they don't see the depth in the book, PM me. This is ridiculous. Still only 15000 something CGA. I don't think there was any need to panic. Now how are you going to buy back in cheaper if nobody else is panicking like a noob?
I agree with you. The issue CGA is facing has a lot of "if"s and "when", won't panic sell either. Sawedoff and the other devs will find a solution, I'm very confident.
Pages: « 1 ... 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 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 ... 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!