Bitcoin Forum
March 28, 2024, 09:12:36 PM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
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 ... 158 »
  Print  
Author Topic: ⚒[CGA] Cryptographic Anomaly - The Elusive Coin⚒  (Read 226214 times)
phzi
Hero Member
*****
Offline Offline

Activity: 700
Merit: 500


View Profile
February 24, 2014, 07:46:10 AM
Last edit: February 24, 2014, 08:01:50 AM by phzi
 #1681

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.
"The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime." -- Satoshi
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1711660356
Hero Member
*
Offline Offline

Posts: 1711660356

View Profile Personal Message (Offline)

Ignore
1711660356
Reply with quote  #2

1711660356
Report to moderator
1711660356
Hero Member
*
Offline Offline

Posts: 1711660356

View Profile Personal Message (Offline)

Ignore
1711660356
Reply with quote  #2

1711660356
Report to moderator
awesomeperson451
Newbie
*
Offline Offline

Activity: 28
Merit: 0


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

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.
phzi
Hero Member
*****
Offline Offline

Activity: 700
Merit: 500


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

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
Newbie
*
Offline Offline

Activity: 36
Merit: 0


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

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?
phzi
Hero Member
*****
Offline Offline

Activity: 700
Merit: 500


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

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
Newbie
*
Offline Offline

Activity: 44
Merit: 0


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

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?
awesomeperson451
Newbie
*
Offline Offline

Activity: 28
Merit: 0


View Profile
February 24, 2014, 08:49:17 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).

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.
sublok
Newbie
*
Offline Offline

Activity: 36
Merit: 0


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


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;
}
oudekaas
Full Member
***
Offline Offline

Activity: 350
Merit: 100



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

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.


▂▂ ▃▃ ▅ ▆ ▇ █ TeraWATT █ ▇ ▆ ▅ ▃▃ ▂▂
≒≒≒≒≒≒≒≒≒≒≒≒≒≒≒≒≒≒≒≒
WEBSITE』『WHITEPAPER
Global LED Adoption Through Blockchain Technology
≒≒≒≒≒≒≒≒≒『ICO IS LIVE』≒≒≒≒≒≒≒≒≒
≒≒≒≒≒≒≒≒≒≒≒≒≒≒≒≒≒≒
TWITTER』『TELEGRAM

phzi
Hero Member
*****
Offline Offline

Activity: 700
Merit: 500


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

@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
Newbie
*
Offline Offline

Activity: 48
Merit: 0


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

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

Activity: 1014
Merit: 708


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

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: 3388
Merit: 1059


View Profile
February 24, 2014, 10:13:05 AM
Last edit: February 24, 2014, 10:25:48 AM by arielbit
 #1693

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: 3388
Merit: 1059


View Profile
February 24, 2014, 10:29:25 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.
how about time added to the equation?time is always changing..
brokedummy
Legendary
*
Offline Offline

Activity: 980
Merit: 1004


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

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?
wzttide
Full Member
***
Offline Offline

Activity: 238
Merit: 100


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

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.
oudekaas
Full Member
***
Offline Offline

Activity: 350
Merit: 100



View Profile WWW
February 24, 2014, 12:43:24 PM
 #1697

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.

I concur!

unique coin, a coin that adapts to it's popularity, great devs and as I can see it is a good investment opportunity whilst only few people are aware of this coin and once the devs find a way around the issues and combined with the scarcity of the coin it will most likely increase the price substantially! Like any investment there is a risk involved, but if you didn't like risk you probably wouldn't consider investing in altcoins anyway.
On all the alts available there is a majority of coins that is offering nothing new apart from being an addition to the pile of crap that is already out there and people will still invest. So I don't worry about a coin with this potential and an honoust team.

Next to that the reason why I got to CGA is that I have been scanning through all the altcoins available and this was the only one I thought that is new and has a uniqueness to it and therefor potential.
I am assuming others will soon follow!

▂▂ ▃▃ ▅ ▆ ▇ █ TeraWATT █ ▇ ▆ ▅ ▃▃ ▂▂
≒≒≒≒≒≒≒≒≒≒≒≒≒≒≒≒≒≒≒≒
WEBSITE』『WHITEPAPER
Global LED Adoption Through Blockchain Technology
≒≒≒≒≒≒≒≒≒『ICO IS LIVE』≒≒≒≒≒≒≒≒≒
≒≒≒≒≒≒≒≒≒≒≒≒≒≒≒≒≒≒
TWITTER』『TELEGRAM

tertius993
Hero Member
*****
Offline Offline

Activity: 1014
Merit: 708


View Profile
February 24, 2014, 12:47:25 PM
 #1698

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.

Likewise, I must confess when the discussions started yesterday I pulled all my buy orders, but didn't sell any.  However, having thought about it and followed the discussions with interest I have now re-instated them and picked up a few coins this morning.

As said there is a risk here, but hey, let us live while we are alive!
R9Generation
Newbie
*
Offline Offline

Activity: 45
Merit: 0


View Profile
February 24, 2014, 01:06:53 PM
 #1699

Whats the matter right now?

I don't understand why people want to change the code again? Its pretty "normal", that this coin is rare, this is a GOOD thing.
It produces fear, when the chain is forked again, especially when people could loose coins wtf. I don't want to loose any coins, and I don't see a necessarity in a code change, could someone explain to me please?
miner_andy
Newbie
*
Offline Offline

Activity: 21
Merit: 0


View Profile
February 24, 2014, 04:12:32 PM
 #1700

Whats the matter right now?

I don't understand why people want to change the code again? Its pretty "normal", that this coin is rare, this is a GOOD thing.
It produces fear, when the chain is forked again, especially when people could loose coins wtf. I don't want to loose any coins, and I don't see a necessarity in a code change, could someone explain to me please?

I agree, you are taking a gamble here. Not many people check forums like this every day to see if they are running everything properly.  The coin is already on markets, and it simply needs to get stable.   If this is another major code change, it needs to be the last.
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 ... 158 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!