Bitcoin Forum
December 14, 2017, 09:28:10 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
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 ... 159 »
  Print  
Author Topic: ⚒[CGA] Cryptographic Anomaly - The Elusive Coin⚒  (Read 224553 times)
mxq
Jr. Member
*
Offline Offline

Activity: 48


View Profile
February 23, 2014, 06:28:33 PM
 #1641

What happened on http://mpos.cga.anomalypool.com/?
This site does not seem to work.
1513286890
Hero Member
*
Offline Offline

Posts: 1513286890

View Profile Personal Message (Offline)

Ignore
1513286890
Reply with quote  #2

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

Activity: 189


View Profile
February 23, 2014, 06:31:59 PM
 #1642

What happened on http://mpos.cga.anomalypool.com/?
This site does not seem to work.

wzttide is looking into it right now. I'm talking to him on IRC.

EDIT: It's working again, sounds like the stratum server got stuck temporarily.
phzi
Hero Member
*****
Offline Offline

Activity: 672


View Profile
February 23, 2014, 06:49:14 PM
 #1643

Panic selling it seems. Sometimes it would be nice if someone thinks they have found a "trick" to keep to private messages with devs.
Why? This is well known stuff... if a dev doesn't know this about their own code, then there is certainly an issue.

Anyone can find this out by reading the source code and running a few simple tests.
oudekaas
Full Member
***
Offline Offline

Activity: 145


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

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.
s4w3d0ff
Sr. Member
****
Offline Offline

Activity: 322


Spray and Pray


View Profile
February 23, 2014, 06:53:07 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.

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

Activity: 145


View Profile
February 23, 2014, 06:58:19 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?
s4w3d0ff
Sr. Member
****
Offline Offline

Activity: 322


Spray and Pray


View Profile
February 23, 2014, 07:03:16 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.

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

Activity: 140


View Profile
February 23, 2014, 07:04:52 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.

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

Activity: 145


View Profile
February 23, 2014, 07:07:55 PM
 #1649

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?
s4w3d0ff
Sr. Member
****
Offline Offline

Activity: 322


Spray and Pray


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

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: 145


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

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

Activity: 672


View Profile
February 23, 2014, 08:11:50 PM
 #1652

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


Spray and Pray


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

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

Activity: 50


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

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: 672


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

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: 672


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

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

Activity: 50


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

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


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

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

Activity: 322


Spray and Pray


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

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: 672


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

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