Bitcoin Forum
November 18, 2018, 05:14:00 AM *
News: Latest Bitcoin Core release: 0.17.0 [Torrent].
 
   Home   Help Search Login Register More  
Pages: « 1 ... 33 34 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 ... 158 »
  Print  
Author Topic: ⚒[CGA] Cryptographic Anomaly - The Elusive Coin⚒  (Read 225325 times)
oudekaas
Full Member
***
Offline Offline

Activity: 263
Merit: 100



View Profile WWW
February 23, 2014, 06:50:12 PM
 #1641

Wow!!! Now that you have found the flaw... Can you please help us with an idea on a fix?  This coin is more original than the other 99% out there, imho !!!
As far as I know, there is no proven way to make a block reward not predictable and not miner selectable at the same time.

It might be possible to use the discovered blockhash to choose reward, but that would likely require some significant changes to the underlying protocol.

so can u not somehow restrict the mining in such way that miners are forced to connect longer before they get a reward?
Like basically if they want to mine this force them to at least connect for a week? so that hopping onto blocks is not an option?

like somepools it takes a long time before you get your actual expected return, can we not built that in.

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

Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1542518040
Hero Member
*
Offline Offline

Posts: 1542518040

View Profile Personal Message (Offline)

Ignore
1542518040
Reply with quote  #2

1542518040
Report to moderator
1542518040
Hero Member
*
Offline Offline

Posts: 1542518040

View Profile Personal Message (Offline)

Ignore
1542518040
Reply with quote  #2

1542518040
Report to moderator
s4w3d0ff
Sr. Member
****
Offline Offline

Activity: 322
Merit: 250


Spray and Pray


View Profile
February 23, 2014, 06:53:07 PM
 #1642

FYI: If have been digging into CGA code a bit more, and if my tests are successful today, I plan to release code that will allow predicting and forcing anomalies on CGA.

It will look like this:
- An odd # block is found.  The script can immediately tell you if the next block is an anomaly or not.
- An even # block is found.  The script can immediately tell you what nTime values to use to GUARANTEE the next block is an anomaly.

Even if you were able to do so, you couldn't predict if you generate the anomaly or if someone else does. That is mining crypto currency... Everyone is competing for the same block at any given time. As soon as you put more hash power into CGA the longer you have to wait unitl you can find that "right moment" to jump into the network. I can see you raising your probability, but actually generating an anomaly EVERY TIME you jump into the network will not happen even if you have +50% of the network hashing power, that would make your odds 1/2 (a coin toss). So while you may of figured out a way to save your mining rigs from mining the 0 blocks, It doesn't mean that you will get an anomaly every time... And if everyone had the script you speak of then your script would go haywire as soon as everyone "jumps" at the same time.

BTC:15D8VaZco22GTLVrFMAehXyif6EGf8GMYV
|⚒|Cryptographic Anomaly|⚒|
oudekaas
Full Member
***
Offline Offline

Activity: 263
Merit: 100



View Profile WWW
February 23, 2014, 06:58:19 PM
 #1643

FYI: If have been digging into CGA code a bit more, and if my tests are successful today, I plan to release code that will allow predicting and forcing anomalies on CGA.

It will look like this:
- An odd # block is found.  The script can immediately tell you if the next block is an anomaly or not.
- An even # block is found.  The script can immediately tell you what nTime values to use to GUARANTEE the next block is an anomaly.

Even if you were able to do so, you couldn't predict if you generate the anomaly or if someone else does. That is mining crypto currency... Everyone is competing for the same block at any given time. As soon as you put more hash power into CGA the longer you have to wait unitl you can find that "right moment" to jump into the network. I can see you raising your probability, but actually generating an anomaly EVERY TIME you jump into the network will not happen even if you have +50% of the network hashing power, that would make your odds 1/2 (a coin toss). So while you may of figured out a way to save your mining rigs from mining the 0 blocks, It doesn't mean that you will get an anomaly every time... And if everyone had the script you speak of then your script would go haywire as soon as everyone "jumps" at the same time.

so what you are saying is that if everyone simply uses that scrypt this coin will work as predicted?
why not implement that scrypt in the pools then?

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

s4w3d0ff
Sr. Member
****
Offline Offline

Activity: 322
Merit: 250


Spray and Pray


View Profile
February 23, 2014, 07:03:16 PM
 #1644

FYI: If have been digging into CGA code a bit more, and if my tests are successful today, I plan to release code that will allow predicting and forcing anomalies on CGA.

It will look like this:
- An odd # block is found.  The script can immediately tell you if the next block is an anomaly or not.
- An even # block is found.  The script can immediately tell you what nTime values to use to GUARANTEE the next block is an anomaly.

Even if you were able to do so, you couldn't predict if you generate the anomaly or if someone else does. That is mining crypto currency... Everyone is competing for the same block at any given time. As soon as you put more hash power into CGA the longer you have to wait unitl you can find that "right moment" to jump into the network. I can see you raising your probability, but actually generating an anomaly EVERY TIME you jump into the network will not happen even if you have +50% of the network hashing power, that would make your odds 1/2 (a coin toss). So while you may of figured out a way to save your mining rigs from mining the 0 blocks, It doesn't mean that you will get an anomaly every time... And if everyone had the script you speak of then your script would go haywire as soon as everyone "jumps" at the same time.

so what you are saying is that if everyone simply uses that scrypt this coin will work as predicted?
why not implement that scrypt in the pools then?

What would happen is that the difficulty would go crazy. Every time the net hash rate would drop to almost 0 and then sky rocket every 3rd block. I have no idea how KGW would react to such a thing.

BTC:15D8VaZco22GTLVrFMAehXyif6EGf8GMYV
|⚒|Cryptographic Anomaly|⚒|
MrE78
Full Member
***
Offline Offline

Activity: 140
Merit: 100


View Profile
February 23, 2014, 07:04:52 PM
 #1645

FYI: If have been digging into CGA code a bit more, and if my tests are successful today, I plan to release code that will allow predicting and forcing anomalies on CGA.

It will look like this:
- An odd # block is found.  The script can immediately tell you if the next block is an anomaly or not.
- An even # block is found.  The script can immediately tell you what nTime values to use to GUARANTEE the next block is an anomaly.

Even if you were able to do so, you couldn't predict if you generate the anomaly or if someone else does. That is mining crypto currency... Everyone is competing for the same block at any given time. As soon as you put more hash power into CGA the longer you have to wait unitl you can find that "right moment" to jump into the network. I can see you raising your probability, but actually generating an anomaly EVERY TIME you jump into the network will not happen even if you have +50% of the network hashing power, that would make your odds 1/2 (a coin toss). So while you may of figured out a way to save your mining rigs from mining the 0 blocks, It doesn't mean that you will get an anomaly every time... And if everyone had the script you speak of then your script would go haywire as soon as everyone "jumps" at the same time.

so what you are saying is that if everyone simply uses that scrypt this coin will work as predicted?
why not implement that scrypt in the pools then?

What would happen is that the difficulty would go crazy. Every time the net hash rate would drop to almost 0 and then sky rocket every 3rd block. I have no idea how KGW would react to such a thing.

Whats the worse? We get some insane diff? It would make the coin even more elusive then. Like master ninja elusive.

Like CEX.IO but better SCRYPT.CC Scrypt based cloud hashing PM for script for auto reinvest
oudekaas
Full Member
***
Offline Offline

Activity: 263
Merit: 100



View Profile WWW
February 23, 2014, 07:07:55 PM
 #1646

FYI: If have been digging into CGA code a bit more, and if my tests are successful today, I plan to release code that will allow predicting and forcing anomalies on CGA.

It will look like this:
- An odd # block is found.  The script can immediately tell you if the next block is an anomaly or not.
- An even # block is found.  The script can immediately tell you what nTime values to use to GUARANTEE the next block is an anomaly.

Even if you were able to do so, you couldn't predict if you generate the anomaly or if someone else does. That is mining crypto currency... Everyone is competing for the same block at any given time. As soon as you put more hash power into CGA the longer you have to wait unitl you can find that "right moment" to jump into the network. I can see you raising your probability, but actually generating an anomaly EVERY TIME you jump into the network will not happen even if you have +50% of the network hashing power, that would make your odds 1/2 (a coin toss). So while you may of figured out a way to save your mining rigs from mining the 0 blocks, It doesn't mean that you will get an anomaly every time... And if everyone had the script you speak of then your script would go haywire as soon as everyone "jumps" at the same time.

so what you are saying is that if everyone simply uses that scrypt this coin will work as predicted?
why not implement that scrypt in the pools then?

What would happen is that the difficulty would go crazy. Every time the net hash rate would drop to almost 0 and then sky rocket every 3rd block. I have no idea how KGW would react to such a thing.

Whats the worse? We get some insane diff? It would make the coin even more elusive then. Like master ninja elusive.

also how long does it take to find a block? like is there not a way to force miners to at least mine so many hours days before they get their return, to stop this from happening?

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

s4w3d0ff
Sr. Member
****
Offline Offline

Activity: 322
Merit: 250


Spray and Pray


View Profile
February 23, 2014, 07:28:05 PM
 #1647

FYI: If have been digging into CGA code a bit more, and if my tests are successful today, I plan to release code that will allow predicting and forcing anomalies on CGA.

It will look like this:
- An odd # block is found.  The script can immediately tell you if the next block is an anomaly or not.
- An even # block is found.  The script can immediately tell you what nTime values to use to GUARANTEE the next block is an anomaly.

Even if you were able to do so, you couldn't predict if you generate the anomaly or if someone else does. That is mining crypto currency... Everyone is competing for the same block at any given time. As soon as you put more hash power into CGA the longer you have to wait unitl you can find that "right moment" to jump into the network. I can see you raising your probability, but actually generating an anomaly EVERY TIME you jump into the network will not happen even if you have +50% of the network hashing power, that would make your odds 1/2 (a coin toss). So while you may of figured out a way to save your mining rigs from mining the 0 blocks, It doesn't mean that you will get an anomaly every time... And if everyone had the script you speak of then your script would go haywire as soon as everyone "jumps" at the same time.

so what you are saying is that if everyone simply uses that scrypt this coin will work as predicted?
why not implement that scrypt in the pools then?

What would happen is that the difficulty would go crazy. Every time the net hash rate would drop to almost 0 and then sky rocket every 3rd block. I have no idea how KGW would react to such a thing.

Whats the worse? We get some insane diff? It would make the coin even more elusive then. Like master ninja elusive.

also how long does it take to find a block? like is there not a way to force miners to at least mine so many hours days before they get their return, to stop this from happening?

That is what difficulty is for. You set the "ideal" time you want the blocks to be solved (CGA is 40 sec) then if a block is solved faster (say 20sec) then the difficulty will go up. If it takes longer to solve a block then 40 sec (say 120 sec) then the difficulty goes down. KGW "smooths" out the fluctuations by averaging the time it took for multiple blocks.

BTC:15D8VaZco22GTLVrFMAehXyif6EGf8GMYV
|⚒|Cryptographic Anomaly|⚒|
oudekaas
Full Member
***
Offline Offline

Activity: 263
Merit: 100



View Profile WWW
February 23, 2014, 07:34:08 PM
 #1648

FYI: If have been digging into CGA code a bit more, and if my tests are successful today, I plan to release code that will allow predicting and forcing anomalies on CGA.

It will look like this:
- An odd # block is found.  The script can immediately tell you if the next block is an anomaly or not.
- An even # block is found.  The script can immediately tell you what nTime values to use to GUARANTEE the next block is an anomaly.

Even if you were able to do so, you couldn't predict if you generate the anomaly or if someone else does. That is mining crypto currency... Everyone is competing for the same block at any given time. As soon as you put more hash power into CGA the longer you have to wait unitl you can find that "right moment" to jump into the network. I can see you raising your probability, but actually generating an anomaly EVERY TIME you jump into the network will not happen even if you have +50% of the network hashing power, that would make your odds 1/2 (a coin toss). So while you may of figured out a way to save your mining rigs from mining the 0 blocks, It doesn't mean that you will get an anomaly every time... And if everyone had the script you speak of then your script would go haywire as soon as everyone "jumps" at the same time.

so what you are saying is that if everyone simply uses that scrypt this coin will work as predicted?
why not implement that scrypt in the pools then?

What would happen is that the difficulty would go crazy. Every time the net hash rate would drop to almost 0 and then sky rocket every 3rd block. I have no idea how KGW would react to such a thing.

Whats the worse? We get some insane diff? It would make the coin even more elusive then. Like master ninja elusive.

also how long does it take to find a block? like is there not a way to force miners to at least mine so many hours days before they get their return, to stop this from happening?

That is what difficulty is for. You set the "ideal" time you want the blocks to be solved (CGA is 40 sec) then if a block is solved faster (say 20sec) then the difficulty will go up. If it takes longer to solve a block then 40 sec (say 120 sec) then the difficulty goes down. KGW "smooths" out the fluctuations by averaging the time it took for multiple blocks.

so can you not restrict connections to pools that don't allow for that? Is there no a way to restrict multipools for connecting? Or at least force them to mine for a certain period before a payout.
I am sure I read somewhere that some pools you only get your full expected return after 2 weeks of mining there?
Just trying to help for obvious reasons Wink

▂▂ ▃▃ ▅ ▆ ▇ █ 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 23, 2014, 08:11:50 PM
 #1649

Okay... so the code I threw together seems to suggest s4w3d0ff led me a bit astray... (and he seems to be leading everyone astray by talking about 50% mining power still leaving you with a coin-flip probability of finding a block...)

Unless I missed something (quite sure I did not), every block appears to be predictable - anomalies occur based on the CURRENT difficulty and the CURRENT block height... not the upcoming difficulty.  So there is no prediction or calculation of nTime required to determine the value of future blocks.  My testing indicates that you can reliably predict if the next block is an anomaly or not, every time, just by calling GetBlockValue from a newly created API function, using block height as a param.  No fancy code is required, and KGW doesn't even come into play here.  Anybody should be able to add a "isNextAnomaly" function to the daemon quite easily.

This means 2 things:

If someone had enough hashing power to build off their own chain (aka, 51% of the network; or using selfish-mining principles, as little as 30% of the network), they could predict the nTime required on the next block that would result in the following block being an anomaly.  Using this system, and by only building on your own chain, you could cause EVERY block to be an anomaly.  A would-be attacker (say, multi-pool), could mine the network, orphaning everyone else's blocks, and get a payout on every block at the same time.

Furthermore, there is absolutely no reason to mine worthless blocks (non-anomaly) - if you wanted to mine CGA, it makes the most sense to mine litecoin (for example) until the next block is an anomaly, and then switch to CGA, switching back as soon as a block is found by the network and the next block is not an anomaly.  The diff is low enough that solo-mining would likely find this fairly effective and profitable.

If pools, or someone solo-mining felt like it, they could also pick nTimes selectively and cause the following block to always be an anomaly (wouldn't necessarily benefit them, but would significantly increase the number of anomalies that occur).

so can you not restrict connections to pools that don't allow for that? Is there no a way to restrict multipools for connecting? Or at least force them to mine for a certain period before a payout.
I am sure I read somewhere that some pools you only get your full expected return after 2 weeks of mining there?
Just trying to help for obvious reasons Wink
Simply put - no.  If I have the longest chain, it must be accepted by the network.  Adding restrictions around this essentially destroys the openness of the protocol, and would require some form of centralization (defeating the purpose of crypto-currencies and proof of work design).
s4w3d0ff
Sr. Member
****
Offline Offline

Activity: 322
Merit: 250


Spray and Pray


View Profile
February 23, 2014, 08:25:58 PM
 #1650

If someone had enough hashing power to build off their own chain (aka, 51% of the network; or using selfish-mining principles, as little as 30% of the network), they could predict the nTime required on the next block that would result in the following block being an anomaly.  Using this system, and by only building on your own chain, you could cause EVERY block to be an anomaly.  A would-be attacker (say, multi-pool), could mine the network, orphaning everyone else's blocks, and get a payout on every block at the same time.

Furthermore, there is absolutely no reason to mine worthless blocks (non-anomaly) - if you wanted to mine CGA, it makes the most sense to mine litecoin (for example) until the next block is an anomaly, and then switch to CGA, switching back as soon as a block is found by the network and the next block is not an anomaly.  The diff is low enough that solo-mining would likely find this fairly effective and profitable.

If pools, or someone solo-mining felt like it, they could also pick nTimes selectively and cause the following block to always be an anomaly (wouldn't necessarily benefit them, but would significantly increase the number of anomalies that occur).


If you have this code I would like to see it. What you explained still requires someone to solve the 0 blocks... The probability of a block EVER generating an anomaly is at the most 1/3. So someone has to solve those 2 other blocks before you can even think about generating an anomaly. Once the difficulty is over 3 then the probability is 1/diff so you would still need to solve the 0 blocks. You can't just have everyone skip over them and make "more" anomalies... that is impossible.

BTC:15D8VaZco22GTLVrFMAehXyif6EGf8GMYV
|⚒|Cryptographic Anomaly|⚒|
omwtothemoon
Newbie
*
Offline Offline

Activity: 50
Merit: 0


View Profile
February 23, 2014, 08:48:21 PM
 #1651

Unless I missed something (quite sure I did not), every block appears to be predictable - anomalies occur based on the CURRENT difficulty and the CURRENT block height... not the upcoming difficulty.  So there is no prediction or calculation of nTime required to determine the value of future blocks.  My testing indicates that you can reliably predict if the next block is an anomaly or not, every time, just by calling GetBlockValue from a newly created API function, using block height as a param.  No fancy code is required, and KGW doesn't even come into play here.  Anybody should be able to add a "isNextAnomaly" function to the daemon quite easily.

What I don't understand is how would you determine the next difficulty so that you know whether or not you create an anomaly, and more important how could you influence the difficulty? It's still completely random when someone will solve a block, so therefore it would be completely random what the next difficulty would be. You can calculate an estimate of this but  theoretically it could take forever. Could you help me, what don't I understand?
phzi
Hero Member
*****
Offline Offline

Activity: 700
Merit: 500


View Profile
February 23, 2014, 08:48:29 PM
 #1652

If someone had enough hashing power to build off their own chain (aka, 51% of the network; or using selfish-mining principles, as little as 30% of the network), they could predict the nTime required on the next block that would result in the following block being an anomaly.  Using this system, and by only building on your own chain, you could cause EVERY block to be an anomaly.  A would-be attacker (say, multi-pool), could mine the network, orphaning everyone else's blocks, and get a payout on every block at the same time.

Furthermore, there is absolutely no reason to mine worthless blocks (non-anomaly) - if you wanted to mine CGA, it makes the most sense to mine litecoin (for example) until the next block is an anomaly, and then switch to CGA, switching back as soon as a block is found by the network and the next block is not an anomaly.  The diff is low enough that solo-mining would likely find this fairly effective and profitable.

If pools, or someone solo-mining felt like it, they could also pick nTimes selectively and cause the following block to always be an anomaly (wouldn't necessarily benefit them, but would significantly increase the number of anomalies that occur).


If you have this code I would like to see it. What you explained still requires someone to solve the 0 blocks... The probability of a block EVER generating an anomaly is at the most 1/3. So someone has to solve those 2 other blocks before you can even think about generating an anomaly. Once the difficulty is over 3 then the probability is 1/diff so you would still need to solve the 0 blocks. You can't just have everyone skip over them and make "more" anomalies... that is impossible.
True, at diff < 3, only every third block can be an anomaly.  This in and of itself is pretty amusingly exploitable by miners - again, why would you mine the obviously worthless blocks?  Let someone else (a fool it seems) waste their hashing power on the 0 reward blocks.  A smart pool operator would know this too - and would be redirecting their hashing power to another coin (with or without telling their miners).  If you can't find a valuable block anyway, then why bother - you can simply _say_ you found a worthless block once and a while, meanwhile keeping the litecoin or dogecoin or whatever you are also mining for yourself.

If diff > 3, then every block can be an anomaly, and therefore all an attacker needs to do is raise the difficulty above 3 while holding 51% of the hashing power (setting the difficulty as desired would be fairly easy - again by abusing KGW and nTime), to ensure every block is an anomaly.

Anyway, I would honestly prefer this coin succeed.  I have made it pretty clear how to selectively mine this coin at this point, and I decided I would prefer not to release the few lines of code required to predict the next block.  CGA seems like a neat idea - what brought me here is that I was considering mining it, but as I usually do, I dug thru the source code first.  Which brought me to this conversation now.

I do hope this coin could succeed, but unless a huge change is made to the protocol, at some point, someone definitely will exploit this huge flaw.
phzi
Hero Member
*****
Offline Offline

Activity: 700
Merit: 500


View Profile
February 23, 2014, 08:50:59 PM
 #1653

What I don't understand is how would you determine the next difficulty so that you know whether or not you create an anomaly. And more important how could you influence the difficulty? It's still completely random when someone will solve a block, so therefore it would be completely random what the next difficulty would be. You can calculate an estimate of this but  theoretically it could take forever. Could you help me, what don't I understand?
You don't need to determine the next difficulty, Anomalies are based on the _current_ difficulty, which becomes evident when you read the source code (and it seems, the OP in this thread even says that pretty clearly).  Basically, (anomaly? yes/no) is determined from height_of_block and difficulty_of_finding_THAT_block.  Not difficulty of finding the following block.

You can influence difficulty by abusing KGW.  If you look into how KGW works, it's entirely based on nTime - block discovery time as a unix timestamp.  Thing is, nTime is very flexible - you can specify at least + or - 100 seconds and it will be accepted by the network.  There is nothing random about nTime - it's chosen by the miner... and nTime is "when" someone solved the block
omwtothemoon
Newbie
*
Offline Offline

Activity: 50
Merit: 0


View Profile
February 23, 2014, 08:56:27 PM
 #1654

What I don't understand is how would you determine the next difficulty so that you know whether or not you create an anomaly. And more important how could you influence the difficulty? It's still completely random when someone will solve a block, so therefore it would be completely random what the next difficulty would be. You can calculate an estimate of this but  theoretically it could take forever. Could you help me, what don't I understand?
You don't need to determine the next difficulty, Anomalies are based on the _current_ difficulty, which is evident when you read the source code.

You can influence difficulty by abusing KGW.  If you look into how KGW works, it's entirely based on nTime - block discovery time as a unix timestamp.  Thing is, nTime is very flexible - you can specify at least + or - 100 seconds and it will be accepted by the network.  There is nothing random about nTime - it's chosen by the miner... and nTime is "when" someone solved the block
Yeah but you can't choose when to complete a block can you? In my understanding, (I'm only looking into these things since today so forgive me if i'm being stupid) you could indeed vary nTime but therefore you would have to have solved the hash already, then send it in when the difficulty would change so that the next block would create an anomaly. To do so you would need immense hash power to beat not only everyone who tries to solve the block, but also beat the exact time you need for the next block to be an anomaly too.
tf2honeybadger
Full Member
***
Offline Offline

Activity: 189
Merit: 100


View Profile
February 23, 2014, 08:58:56 PM
 #1655

phzi- would you join us in IRC to discuss this further? #cganomaly on freenode.
s4w3d0ff
Sr. Member
****
Offline Offline

Activity: 322
Merit: 250


Spray and Pray


View Profile
February 23, 2014, 08:59:21 PM
 #1656

If someone had enough hashing power to build off their own chain (aka, 51% of the network; or using selfish-mining principles, as little as 30% of the network), they could predict the nTime required on the next block that would result in the following block being an anomaly.  Using this system, and by only building on your own chain, you could cause EVERY block to be an anomaly.  A would-be attacker (say, multi-pool), could mine the network, orphaning everyone else's blocks, and get a payout on every block at the same time.

Furthermore, there is absolutely no reason to mine worthless blocks (non-anomaly) - if you wanted to mine CGA, it makes the most sense to mine litecoin (for example) until the next block is an anomaly, and then switch to CGA, switching back as soon as a block is found by the network and the next block is not an anomaly.  The diff is low enough that solo-mining would likely find this fairly effective and profitable.

If pools, or someone solo-mining felt like it, they could also pick nTimes selectively and cause the following block to always be an anomaly (wouldn't necessarily benefit them, but would significantly increase the number of anomalies that occur).


If you have this code I would like to see it. What you explained still requires someone to solve the 0 blocks... The probability of a block EVER generating an anomaly is at the most 1/3. So someone has to solve those 2 other blocks before you can even think about generating an anomaly. Once the difficulty is over 3 then the probability is 1/diff so you would still need to solve the 0 blocks. You can't just have everyone skip over them and make "more" anomalies... that is impossible.
True, at diff < 3, only every third block can be an anomaly.  This in and of itself is pretty amusingly exploitable by miners - again, why would you mine the obviously worthless blocks?  Let someone else (a fool it seems) waste their hashing power on the 0 reward blocks.  A smart pool operator would know this too - and would be redirecting their hashing power to another coin (with or without telling their miners).  If you can't find a valuable block anyway, then why bother - you can simply _say_ you found a worthless block once and a while, meanwhile keeping the litecoin or dogecoin or whatever you are also mining for yourself.

If diff > 3, then every block can be an anomaly, and therefore all an attacker needs to do is raise the difficulty above 3 while holding 51% of the hashing power (setting the difficulty as desired would be fairly easy - again by abusing KGW and nTime), to ensure every block is an anomaly.

Anyway, I would honestly prefer this coin succeed.  I have made it pretty clear how to selectively mine this coin at this point, and I decided I would prefer not to release the few lines of code required to predict the next block.  CGA seems like a neat idea - what brought me here is that I was considering mining it, but as I usually do, I dug thru the source code first.  Which brought me to this conversation now.

I do hope this coin could succeed, but unless a huge change is made to the protocol, at some point, someone definitely will exploit this huge flaw.

Please PM me this code so I can determine if I need to make a fix.

BTC:15D8VaZco22GTLVrFMAehXyif6EGf8GMYV
|⚒|Cryptographic Anomaly|⚒|
phzi
Hero Member
*****
Offline Offline

Activity: 700
Merit: 500


View Profile
February 23, 2014, 09:04:37 PM
 #1657

Yeah but you can't choose when to complete a block can you? In my understanding, (I'm only looking into these things since today so forgive me if i'm being stupid) you could indeed vary nTime but therefore you would have to have solved the hash already, then send it in when the difficulty would change so that the next block would create an anomaly. To do so you would need immense hash power to beat not only everyone who tries to solve the block, but also beat the exact time you need for the next block to be an anomaly too.

nTime IS when you completed the block.  So yes, you definitely can choose.  and nTime is part of calculating the hash.  No need to actually submit a block at a specific time, just vary nTime as needed.

Please PM me this code so I can determine if I need to make a fix.
The code is in your own client - just call getBlockValue ?
Molitor
Member
**
Offline Offline

Activity: 70
Merit: 10



View Profile
February 23, 2014, 09:14:06 PM
 #1658

If diff > 3, then every block can be an anomaly, and therefore all an attacker needs to do is raise the difficulty above 3 while holding 51% of the hashing power (setting the difficulty as desired would be fairly easy - again by abusing KGW and nTime), to ensure every block is an anomaly.

Aren't you glossing over the all an attacker needs to do is raise the difficulty above 3 while holding 51% of the hashing power a bit? Exploiting this aspect of the flaw is out of the reach of the vast majority of miners, and even so, not a lot of attackers could use it simultaneously. In practice, wouldn't this just result in an arms race among attackers vying for the 51% making the whole thing not profitable?
MrE78
Full Member
***
Offline Offline

Activity: 140
Merit: 100


View Profile
February 23, 2014, 09:28:38 PM
 #1659

If diff > 3, then every block can be an anomaly, and therefore all an attacker needs to do is raise the difficulty above 3 while holding 51% of the hashing power (setting the difficulty as desired would be fairly easy - again by abusing KGW and nTime), to ensure every block is an anomaly.

Aren't you glossing over the all an attacker needs to do is raise the difficulty above 3 while holding 51% of the hashing power a bit? Exploiting this aspect of the flaw is out of the reach of the vast majority of miners, and even so, not a lot of attackers could use it simultaneously. In practice, wouldn't this just result in an arms race among attackers vying for the 51% making the whole thing not profitable?


I think he was looking for an flaw in the coins design and the best he could up with for manipulation is a 51% attack that can take most (not all) +1 blocks.

We all know and are aware a 51% can be bad however how often does one happen? Now yes If I joined with two of my buddies we could do a 60% attack on the network just because not a lot of people have caught on to the value of this coin. It does not mean I am running out to join forces to control a coin.

However really with any coin under 1ghs network will always be able to be controlled by a group if desired so the best thing we can do is spread the word around and get more miners on board.

So his big reveal nothing that is new really.

Like CEX.IO but better SCRYPT.CC Scrypt based cloud hashing PM for script for auto reinvest
phzi
Hero Member
*****
Offline Offline

Activity: 700
Merit: 500


View Profile
February 23, 2014, 10:03:39 PM
 #1660

Well, I'm chatting with the devs about this now.  It's definitely not only a flaw that requires 51% attacks - it's a flaw that if fully realized by pools, could cause the network to grind to a complete stop (with nobody mining worthless blocks).  It's also something that more then anything, WILL be exploited by multi-pools that already do so for other variable block reward coins, if this coin gets big enough without a patch.
Pages: « 1 ... 33 34 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 ... 158 »
  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!