I don’t
Ah… Ohh… You got me. I think you found a major flaw…
NOT!![/quote]
Sahkan, don’t become rude, please. This is not about who is right and who is wrong. It is about making Peercoin a safe investment, which people will one day trust so much that they will invest in it like in physical gold.
[quote=“sahkan, post:18, topic:3757”]You keep describing bitcoin where there is a blockTrust: in bitcoin we trust the blocks based on the hash, so it goes from block 1 to 2 to 3 to 4 etc.
Since Peercoin evolved, we have a ChainTrust so in a chain where alpha blocks are POS and numeric Are POW like so: A 1 2 3 B 5 6 7 8 9 10 11 C the ChainTrust goes A to B to C[/quote]
If B comes in only after 7, then it’s already too late.
[quote=“sahkan, post:18, topic:3757”]the POW blocks are checkpointed like so:
[i]// Automatically select a suitable sync-checkpoint
uint256 AutoSelectSyncCheckpoint()
{
// Proof-of-work blocks are immediately checkpointed
// to defend against 51% attack which rejects other miners block
// Select the last proof-of-work block
const CBlockIndex *pindex = GetLastBlockIndex(pindexBest, false);
// Search forward for a block within max span and maturity window
while (pindex->pnext && (pindex->GetBlockTime() + CHECKPOINT_MAX_SPAN <= pindexBest->GetBlockTime() || pindex->nHeight + std::min(6, nCoinbaseMaturity - 20) <= pindexBest->nHeight))
pindex = pindex->pnext;
return pindex->GetBlockHash();
}[/i]
Ref: https://github.com/ppcoin/ppcoin/blob/master/src/checkpoints.cpp
Therefore your 7 blocks will never replace the first 6 because you can’t fork at a POW block (but I already mentioned that and so did masterofdisaster before you even wrote your post) and the block chain will follow the next POS block with highest ChainTrust (difficulty).[/quote]
If checkpointing is the only protection against the Proof-of-work attack that I have described above, then this is very poor.
In the long run we want to get rid of checkpointing, don’t we?
We need a better protection against a Super-Hashrate Proof-of-Work attack.
A transaction should be regarded as confirmed only after 6 PoS blocks.
Thehuntergames,
don’t call it 51% PoW attack, because it requires much more hashrate than that.
Lets call it Superhashrate-attack, or 10000%-attack.
All blockchains can orphan, thats why you need to wait a couple confirmations as it gets harder to fork.
As you dont use peercoins for coffee payments rather for settlements I am fine waiting an hour for 6 confirmations.
when ever such a 10000% attack happens I’ll know it and everybody will be buzzing on the chatbox.
Years from now, but at some point ppc will be entirely pos so theres that…
At least 6 blocks, one of them being a PoS block. This should be enough.
An other way to circumvent the flaw would be to (highly) rise the PoW difficulty for consecutive PoW blocks.
Ah… Ohh… You got me. I think you found a major flaw…
NOT!![/quote]
Sahkan, don’t become rude, please. This is not about who is right and who is wrong. It is about making Peercoin a safe investment, which people will one day trust so much that they will invest in it like in physical gold.
[quote=“sahkan, post:18, topic:3757”]You keep describing bitcoin where there is a blockTrust: in bitcoin we trust the blocks based on the hash, so it goes from block 1 to 2 to 3 to 4 etc.
Since Peercoin evolved, we have a ChainTrust so in a chain where alpha blocks are POS and numeric Are POW like so: A 1 2 3 B 5 6 7 8 9 10 11 C the ChainTrust goes A to B to C[/quote]
If B comes in only after 7, then it’s already too late.
[quote=“sahkan, post:18, topic:3757”]the POW blocks are checkpointed like so:
[i]// Automatically select a suitable sync-checkpoint
uint256 AutoSelectSyncCheckpoint()
{
// Proof-of-work blocks are immediately checkpointed
// to defend against 51% attack which rejects other miners block
// Select the last proof-of-work block
const CBlockIndex *pindex = GetLastBlockIndex(pindexBest, false);
// Search forward for a block within max span and maturity window
while (pindex->pnext && (pindex->GetBlockTime() + CHECKPOINT_MAX_SPAN <= pindexBest->GetBlockTime() || pindex->nHeight + std::min(6, nCoinbaseMaturity - 20) <= pindexBest->nHeight))
pindex = pindex->pnext;
return pindex->GetBlockHash();
}[/i]
Ref: https://github.com/ppcoin/ppcoin/blob/master/src/checkpoints.cpp
Therefore your 7 blocks will never replace the first 6 because you can’t fork at a POW block (but I already mentioned that and so did masterofdisaster before you even wrote your post) and the block chain will follow the next POS block with highest ChainTrust (difficulty).[/quote]
If checkpointing is the only protection against the Proof-of-work attack that I have described above, then this is very poor.
In the long run we want to get rid of checkpointing, don’t we?
We need a better protection against a Super-Hashrate Proof-of-Work attack.
A transaction should be regarded as confirmed only after 6 PoS blocks.[/quote]
First off, I was not trying to be rude but responded in a manner that you did when you included the youtube link few posts back.
Second of all, I see that you either are not reading what I write or fail to understand it. I must be a terrible educator.
You can have 1000 blocks before B and still will not be able to do the attack.
Yes, we will get rid of the hard-coded checkpoints not the moving check point (I believe).
Thehuntergames,
don’t call it 51% PoW attack, because it requires much more hashrate than that.
Lets call it Superhashrate-attack, or 10000%-attack.[/quote]
The name "51% attack: refers to controlling 51% or more of the total hashing power on the network. If you had control of everything that hashes on the Peercoin network you can only do 100% therefore the name “10000% attack” would not be proper. Of course the actual hashing rate does not matter.
I’m not sure that you are talking about the same attack. The blockchain is safe on the long run, but what happens between block A and block B ?
I was thinking (hoping) that peercoin is aiming to be a completely decentral coin.
This requires getting rid of any checkpointing…
Thehuntergames,
don’t call it 51% PoW attack, because it requires much more hashrate than that.
Lets call it Superhashrate-attack, or 10000%-attack.[/quote]
The name "51% attack: refers to controlling 51% or more of the total hashing power on the network. If you had control of everything that hashes on the Peercoin network you can only do 100% therefore the name “10000% attack” would not be proper. Of course the actual hashing rate does not matter.[/quote]
A Proof-of-work block is found about once every 50-70 mintues in Peercoin. So to find a block once every minute and be able to perform an attack, you will need 50-70 times more hashrate than the rest of the network. The difficulty would later increase by the same factor, but not soon enough to prevent an attack. And the attacker needs to mine on two chains, so he will need 100-140 times more hashrate.
The percentage (10000%) refers to the amount of hashrate that the attacker needs to have compared to the amount of hashrate that was hashing in the network before the attack.
I’m not sure that you are talking about the same attack. The blockchain is safe on the long run, but what happens between block A and block B ?[/quote]
Look at my prior posts, and the peercoin code with this comment:
// Proof-of-work blocks are immediately checkpointed
// to defend against 51% attack which rejects other miners block
Thehuntergames,
don’t call it 51% PoW attack, because it requires much more hashrate than that.
Lets call it Superhashrate-attack, or 10000%-attack.[/quote]
The name "51% attack: refers to controlling 51% or more of the total hashing power on the network. If you had control of everything that hashes on the Peercoin network you can only do 100% therefore the name “10000% attack” would not be proper. Of course the actual hashing rate does not matter.[/quote]
A Proof-of-work block is found about once every 50-70 mintues in Peercoin. So to find a block once every minute and be able to perform an attack, you will need 50-70 times more hashrate than the rest of the network. The difficulty would later increase by the same factor, but not soon enough to prevent an attack. And the attacker needs to mine on two chains, so he will need 100-140 times more hashrate.
The percentage (10000%) refers to the amount of hashrate that the attacker needs to have compared to the amount of hashrate that was hashing in the network before the attack.[/quote]
Let me ask you this; after reading my posts do you understand that the POW attack that you described in your original post cannot be done in Peercoin?
Sorry if my question is off-top, i didnt found better thread.
After how many blocks new mint coins will be available as balance in peercoind?
After how many blocks diff will be recalculated?
Thank you
520
1
[quote=“sahkan, post:18, topic:3757”] // Proof-of-work blocks are immediately checkpointed
// to defend against 51% attack which rejects other miners block
// Select the last proof-of-work block
const CBlockIndex *pindex = GetLastBlockIndex(pindexBest, false);
// Search forward for a block within max span and maturity window
while (pindex->pnext && (pindex->GetBlockTime() + CHECKPOINT_MAX_SPAN <= pindexBest->GetBlockTime() || pindex->nHeight + std::min(6, nCoinbaseMaturity - 20) <= pindexBest->nHeight))
pindex = pindex->pnext;
Therefore your 7 blocks will never replace the first 6 because you can’t fork at a POW block[/quote]
If the network can’t fork at a POW block how are pow block conflics resolved? Sorry I don’t quite understand " Proof-of-work blocks are immediately checkpointed".
Which pool owns the address PQ9BK7xeZJFRTozq8PUkhtzX2GGn8qDgWB?
[quote=“mhps, post:35, topic:3757”][quote=“sahkan, post:18, topic:3757”] // Proof-of-work blocks are immediately checkpointed
// to defend against 51% attack which rejects other miners block
// Select the last proof-of-work block
const CBlockIndex *pindex = GetLastBlockIndex(pindexBest, false);
// Search forward for a block within max span and maturity window
while (pindex->pnext && (pindex->GetBlockTime() + CHECKPOINT_MAX_SPAN <= pindexBest->GetBlockTime() || pindex->nHeight + std::min(6, nCoinbaseMaturity - 20) <= pindexBest->nHeight))
pindex = pindex->pnext;
Therefore your 7 blocks will never replace the first 6 because you can’t fork at a POW block[/quote]
If the network can’t fork at a POW block how are pow block conflics resolved? Sorry I don’t quite understand " Proof-of-work blocks are immediately checkpointed".[/quote]
Any block that was not selected gets orphaned.