Topic: [ANN][XCN] Cryptonite | 1st mini-blockchain coin | M7 PoW | No Premine - page 155. (Read 578501 times)
July 31, 2014, 11:52:05 PM
Can't decide whether to finish the miner quickly or optimize it to death...
August 01, 2014, 02:47:19 AM
Making a GPU miner for this is not that easy because of the exotic algo's used (i.e. ripemd / tiger). You need knowledge how to port the algo's to opencl... It is definitely possible but hard to do
August 01, 2014, 02:24:11 AM
How GPU mining?
Who can give a GPU software and method？
Who can give a GPU software and method？
No GPU miner available.
Is there any windows CPU miner available?
Yeah, I think it's in the OP. Only solo mining, though - pool software was released, but no ops yet.
I found only sources in the OP.
August 01, 2014, 02:21:22 AM
How GPU mining?
Who can give a GPU software and method？
Who can give a GPU software and method？
No GPU miner available.
Is there any windows CPU miner available?
August 01, 2014, 02:05:52 AM
How GPU mining?
Who can give a GPU software and method？
Who can give a GPU software and method？
August 01, 2014, 01:55:13 AM
How many coins there currently are?
August 01, 2014, 01:53:41 AM
August 01, 2014, 01:27:51 AM
- Block reward: changes every block
So what a block reward?
So what a block reward?
August 01, 2014, 01:15:10 AM
@sbgyuff520: yes that looks correct.
August 01, 2014, 01:04:14 AM
{
"blocks" : 7444,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 57800.94800027,
"errors" : "",
"genproclimit" : 6,
"networkhashps" : 1115930737,
"pooledtx" : 0,
"testnet" : false,
"generate" : true,
"hashespersec" : 272866
}
Correct?
Cryptonite version v0.1.1.0-unk-beta (64-bit)
"blocks" : 7444,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 57800.94800027,
"errors" : "",
"genproclimit" : 6,
"networkhashps" : 1115930737,
"pooledtx" : 0,
"testnet" : false,
"generate" : true,
"hashespersec" : 272866
}
Correct?
Cryptonite version v0.1.1.0-unk-beta (64-bit)
August 01, 2014, 12:54:55 AM
Really? I can still find a block a day with only a combined 32 cores (actually only 28 cores in practice)
August 01, 2014, 12:34:25 AM
I already stopped 1 day ago, smaller miners may return when pool is available. Right now mining with less than 100 cores seems like accelerating AGW
July 31, 2014, 07:23:03 PM
Wolf0's least favorite coin is PETA coin.
Heh, I actually laughed at that a bit.
August 01, 2014, 12:29:13 AM
Can't decide whether to finish the miner quickly or optimize it to death...
I stop mining this coin!!! Its too hard for me with two 32 cores!
Frustrating to read this.. coins being mined by few people. Hopefully it doesn't matter in the long run when the gpu miner is released to everyone.
August 01, 2014, 12:26:25 AM
Can't decide whether to finish the miner quickly or optimize it to death...
I stop mining this coin!!! Its too hard for me with two 32 cores!
July 31, 2014, 06:26:22 PM
Hahaha, I knew Wolf0 would be around quick.
I might still not know about this coin if there weren't a half-dozen people on IRC bugging me about it.
July 31, 2014, 11:47:16 PM
The design looks very vulnerable to 51% type attacks, much more so than Bitcoin even. Wouldn't trust it with my money.
At least you have taken the time to come up with a reasonably valid criticism that is worth talking about. I believe what you are referring to is the Secret Chain Attack. Following quote taken from the weaknesses and attack vectors wiki page.Quote
The Secret Chain Attack
If an attacker had enough hashing power he could generate a fake chain in secret using the real proof chain but a fake account tree. He would need to out-pace the real mini-blockchain for a full cycle until there's no evidence left to indicate his account tree is fake and then start broadcasting the fake chain.
This wont affect older nodes who have been validating blocks for longer than the cycle of the mini-blockchain because they can detect the fake chain or simply ignore super long forks. In Cryptonite existing nodes will just stick with the chain they have if the origin point of the fork appears to be older than the cycle time.
So there's no way the attacker could trick existing nodes to accept his fake chain, but new nodes are still at risk. New nodes have no way of determining which is the valid chain because they have no history of what happened before the oldest block in the mini-blockchain. Using some sort of consensus mechanism is not perfect either.
Minimizing risk of attack success
If a new node detects multiple chains which originate from the same proof chain it can try to query other nodes for older blocks all the way to the block in which the competing chains diverged and if no one around has this long history (no one is required to have it) the user can either take a chance on the chain the nodes recieves first, or refuse to participate in the network until one of the chains has won the race.
The user will be warned when any type of fork longer than 24 hours is detected. The user could also manually point the node to the correct chain with the use of a community checkpoint. The community will release a new checkpoint as quickly as possible if this situation does arise. When the checkpoint is released new nodes will be able to safely join the network and help the other nodes work against the attacker.
Since this attack will only put new nodes at risk and since it will most likely never happen, let alone succeed, this strategy is an acceptable contingency plan for dealing with the attack. Worse case scenario is that new nodes have to wait until the situation has been resolved or wait until a new checkpoint is released which points to the real chain. Anyone already running a node would not be affected in any way.
In summary, this attack is unconcerning and unlikely for several reason:
* requires an incredible amount of hashing power
* requires that no one has historic blockchain data
* only nodes which haven't synced for more than a week are susceptible
* when all else fails new nodes can resolve the problem with a checkpoint
* attack will never succeed due to checkpoints and probably could never be profitable
If an attacker had enough hashing power he could generate a fake chain in secret using the real proof chain but a fake account tree. He would need to out-pace the real mini-blockchain for a full cycle until there's no evidence left to indicate his account tree is fake and then start broadcasting the fake chain.
This wont affect older nodes who have been validating blocks for longer than the cycle of the mini-blockchain because they can detect the fake chain or simply ignore super long forks. In Cryptonite existing nodes will just stick with the chain they have if the origin point of the fork appears to be older than the cycle time.
So there's no way the attacker could trick existing nodes to accept his fake chain, but new nodes are still at risk. New nodes have no way of determining which is the valid chain because they have no history of what happened before the oldest block in the mini-blockchain. Using some sort of consensus mechanism is not perfect either.
Minimizing risk of attack success
If a new node detects multiple chains which originate from the same proof chain it can try to query other nodes for older blocks all the way to the block in which the competing chains diverged and if no one around has this long history (no one is required to have it) the user can either take a chance on the chain the nodes recieves first, or refuse to participate in the network until one of the chains has won the race.
The user will be warned when any type of fork longer than 24 hours is detected. The user could also manually point the node to the correct chain with the use of a community checkpoint. The community will release a new checkpoint as quickly as possible if this situation does arise. When the checkpoint is released new nodes will be able to safely join the network and help the other nodes work against the attacker.
Since this attack will only put new nodes at risk and since it will most likely never happen, let alone succeed, this strategy is an acceptable contingency plan for dealing with the attack. Worse case scenario is that new nodes have to wait until the situation has been resolved or wait until a new checkpoint is released which points to the real chain. Anyone already running a node would not be affected in any way.
In summary, this attack is unconcerning and unlikely for several reason:
* requires an incredible amount of hashing power
* requires that no one has historic blockchain data
* only nodes which haven't synced for more than a week are susceptible
* when all else fails new nodes can resolve the problem with a checkpoint
* attack will never succeed due to checkpoints and probably could never be profitable
July 31, 2014, 11:43:01 PM
Isnt that alot? You think it will hold its value?
More than that, the fascination with "how many coins" is absurd. It is percentage of coins that matters, not how many of them. But companies spend money on legal and administrative fees to do stock splits so I guess people are just dumb.
July 31, 2014, 11:17:10 PM
Isnt that alot? You think it will hold its value?
Thank so much for your response, i was just trying to understand how that works. I am all in....
July 31, 2014, 11:15:13 PM
Isnt that alot? You think it will hold its value?
Jump to: