Weekly Update #181
[ul][li]Peercoin v0.5.1 still under final testing. Expect release late February. This is a mandatory upgrade release, so once annouced, users should have at least several weeks time window to upgrade their client wallets.[/li][/ul]
Have fun!
Hi Sunny,
Given the enourmous hashing power on the bitcoin network compared to peercoin, I would like to know what protects Peercoin’s blockchain during the time between two Proof-of-stake minted blocks A and B ?
I mentioned this here in the thread for Peercoin v.0.5.1. release:
https://www.peercointalk.org/index.php?topic=4376.msg41682#msg41682
and in greater detail in this thread:
https://www.peercointalk.org/index.php?topic=4383.0
An answer from you would be much appreciated. If the blockchain is not protected against such an attack, a fix should be quite easy and could be implemented in Peercoin v.0.5.
Just to clarify, the attack can be done by swiftly mining two sets of blocks, one of length 6 and the other of length 7, between two PoS blocks (assume i have a majority of the hashpower in the universe), one sending my peercoins to address A and another for address B. I put the 6 blocks sending my ppc to A, get paid for it, then put out the fork chain with 7 blocks. The next minter will mint on my 7 instead of the 6. Ignoring checkpointing, this seems to be an issue with a pretty straightforward solution: require 6 pos confirmations, pow doesnt count.
thanks Nagalim, you nailed it down. 
Ötzi -
I can’t really tell if Nagalim is agreeing with you or not, but pay attention to his “solution”
The minimum number of confirmations to accept is NOT a protocol level parameter. It is up to an individual to determine how many confirmations they would like to see prior to exchanging goods. If you don’t feel comfortable relying on POW blocks then wait for your desired number of POS blocks.
However, you should know that nodes that have been present on the network for some time are not going to arbitrarily discard valid blocks just because an attacker presents an alternative longer chain. The malicious transactions that the attacker places in the alternative chain will be rejected by all the nodes that have already validated the original transactions.
Btw, Bter only waits for two confirmations before crediting a deposit.
Hi learnmore,
do you have detailed knowledge about the exact consensus rules in peercoin? I have not found any detailed documentation, and I don’t think any rules in a PoS/PoW coin can prevent an attack with a hashpower that is orders of magnitudes higher that the current network.
If valid Proof-of-work blocks were never discarded, the Peercoin blockchain would fork regularly. They must be discarded if a Proof-of-stake minted block is received that was minted at the same chain height or higher, i.e. on top of the previous block or on top of other Proof-of-work mined blocks.
If that’s how the current protocol works, then the attacker with the Super-high-Hashpower could modify the attack to perform a double-spend:
Secretly mine two different blocks 1a and 1b on top of block A, and broadcast them to different notes simultaneously. This will split the network until a Proof-of-stake block is found. Block 1a in chain I includes the payment transaction, block 1b in chain II includes a transactions that sends the same coins back to the attacker. The attacker continues to mine on both chains I and II, and broadcasts the blocks until they reach blocks 6a and 6b.
By that moment, the standard client will show both transactions as confirmed, on their respective chains.
After that, lets assume a node in chain II finds block B (Proof-of-stake minted). Block B and blocks 1b,2b,3b,4b,5b and 6b must be accepted on chain I, otherwise the blockchain would remain split forever.
The recipient of the payment transaction on chain I now loses his coins. Double-spend complete.
Well, yes, a 51% attack is a risk for any POW scheme. And, yes, the risk is heightened against any SHA-256 algorithm due to the built-up BTC mining industry. This has led to the the swift demise of many alts which merely replicated BTC.
A 51% attack against PPC, however, is a bit more problematic for the attacker because they have to be certain they can complete the attack before the next POS block. If you’re talking “orders of magnitude” above the current PPC hashrate, it’s probably more rational to just mine BTC rather than risk total loss in a failed 51% POW attack on PPC.
Sunny has already set the weight of POW blocks very low. What more would you suggest? As I said, if you’re making a high stakes transaction just wait for a POS confirmation to feel more comfortable.
Defaults are a big deal. How about we get the standard client to only consider PoS blocks when counting confirmations?
that’s a neat idea. To be precise: counting to 6 pos confirmations before the clock-icon changes in the first column. The other counters, e.g. when you stake or made a new tx, stays as it is.