Actually you don’t even get these extra chances because the other nodes won’t propagate you duplicate block (see the previous posts).
So to get this little benefit you first need that a significant part of network run a modified version of peercoin that brings them more dangers than advantages (the dangers being DoS vulnerability and an unstable network with frequent chain forks, and the advantage being you can mint multiple chains…).
I see, thanks for explaining it.
Yes you can generate the 10 hashes of the next 10 seconds in 1 second. But if you repeat the process the next second, you’ll get 9 hashes you already have and only 1 new. So you’re back to 1 per second.
You can generate hashes for many seconds in advance, but your block may be rejected if the timestamp is too far in the future.[/quote]
I haven’t thought of this. Very well thought-out algorithm.
I just wanted to take a moment to thank everyone involved in this thread. I am new to PPC, I’ve dabbled in BTC for a little awhile and tossed around a few Alt-Coins, have done some solo and pool mining. No major investments on any one front, just testing the waters.
I have to say this forum is impressive, yet mind boggling. I have spent the last near 10 hours reading various threads and links within threads about the source code and various theory and some proofs. All of it VERY impressive and, unfortunately some of it is still over my head as I am so very new to the concept of POS. I get the general idea though.
I really love the concept of PPC, is it the final iteration? Or will yet another Alt-Coin pick up and change the code again and make it different.
I don’t know, but after reading the idea behind PPC and the people that are so very passionate, I have to say I’m totally stoked to take my first steps!
So again, thank you all for your amazing information!
One solution has been suggested by Sigmike here:
http://www.peercointalk.org/index.php?topic=2871.msg26193;topicseen#msg26193
I think it’s being implemented for version 0.5:
http://www.peercointalk.org/index.php?topic=2783.msg28885#msg28885
Someone could confirm that?
Sigmike’s idea:
[quote=“sigmike”]when we receive a block with an already seen stake, we reject both blocks instead of only the second one. That means we move the blockchain one block backward.
We would still accept the block if the new main chain depends on it.[/quote]
I don’t see how this discourages minting on several chains. Wouldn’t the attacker simply stop minting on competing chains after a block is found?
Chronos,
I don’t understand why an attacker should stop minting on competing chains after a block found.
I think sigmike proposed the following: If someone finds a new block and broadcasts it for two chains, then other nodes will see this and punish him by deleting both blocks, i.e. they wont mint on top of the chains with these new block. As a result the ‘evil minter’ does not get his reward for finding the block.
That’s not what happens, as far as I understand the system. A block that’s valid on one chain may not be valid on another.
Instead, an attacker mints on two chains, doubling the chances of finding a block on either chain. Once found, the other chain can be abandoned, avoiding Sigmike’s penalty. This only works if the chain-with-new-block ends up being the winning chain, but this becomes more likely once the attacker’s block is added.
I could be wrong. 
no, a block - better the kernel, used to find this block - is valid on each chain.
You may wanna look over here: [link] https://github.com/ppcoin/ppcoin/blob/master/src/kernel.cpp#L313
[/link]
The important code is:
CDataStream ss(SER_GETHASH, 0);
ss << nStakeModifier;
ss << nTimeBlockFrom << nTxPrevOffset << txPrev.nTime << prevout.n << nTimeTx;
hashProofOfStake = Hash(ss.begin(), ss.end());
// Now check if proof-of-stake hash meets target protocol
if (CBigNum(hashProofOfStake) > bnCoinDayWeight * bnTargetPerCoinDay)as you can see only static data is included in the calculations for the block. The only difference for the two chains might be the PosDifficulty. But if they differ too much that would mean that one chain is already falling behind.
Hi guys,
A few weeks ago I published a draft proposal to solve this problem, after more thoughts on my side I improved it and republished it today.
You can read it here: https://gist.github.com/mquandalle/7fe702a595f07f4b0f81
I would love to know what you think of it!
mquandalle - Very nice presentation of your proposal! It is an interesting idea, and I’ll definitely be watching to see what others think of it.
However, I’m having a little trouble understanding how the proposed burn transaction actually solves the issue. As you point out, malicious minters have no incentive to broadcast any transaction to the main chain until the attack chain is long enough to overtake the main chain. I think you try to address this objection here:
To solve this attack, a solution would be to use the same rule that as classical proof-of-work algorithms, ie the first block received is the legitimate block. And minter shouldn't broadcast their block ahead of time.
The problem is that I don’t think there is any absolute way to prove that one block was broadcast on the network before any other. Obviously, for any continuously running node there will be internal awareness of which block arrived first, but for all new clients downloading the blockchain, I’m afraid the attacker’s chain may be preferred.
Adding to my comments above… I believe sigmike’s simple solution of rejecting any two or more blocks from the same stake is sufficient to discourage minters from haphazardly minting on all chains because it essentially accomplishes the very thing you propose (i.e. it destroys coin-age).
Deliberate, calculated attacks with very large stored coin-age are still possible but at least with v0.5 the average minter won’t be inadvertently supporting attacks by trying to eke a slight advantage minting all chains.
mquandalle - Indeed a very nice presentation !
To solve this attack, a solution would be to use the same rule that as classical proof-of-work algorithms, ie the first block received is the legitimate block. And minter shouldn't broadcast their block ahead of time.
Unfortunately, this is the sore spot. Imagine two blocks are found nearby simultaneously and half of network gets the first block and the other half the other block. If the nodes would follow your protocol, we would have blockchain split.
Even if you do, that does not mean you are double mining the peercoin chain.
Think of it as merge mining, you can merge mine as many coins as you want, and this happens now with IXC, IOC and Namecoin with Bitcoin.
It doesnt matter how many you merge mine.
Selfish mining is not working with PoS because it’s not economically sound, isn’t it? You could do it, but you cannot gain from it since your reward is limited to 1% and independent of how many blocks you mint.
You could try to double spend, but for that you have to produce 6 block in a row. If you have 48% of all peercoin you would have 8% of the network minting power for for the first block, slightly more for the second block, even more for the third block and so on. But 0.080.10.120.140.16*0.18gives a very small chance of successful double spending. In average you need something like 5 years to mint 6 PoS blocks in a row when you have half of all coins.
Is that a problem?
Yes. Some one has been finding 6 blocks in a roll every a few months. Cryptoblog - notícias sobre bitcoin e criptomoedas!
To answer some questions raised here I’d like to clarify something.
In the Peercoin Proof of Stake process you look for a valid kernel at a particular timestamp. You don’t look for a valid block. A kernel is an unspent output.
Once you find a valid kernel you can create as many blocks as you want using the same kernel.
Minting on all competing chains means that once you’ve found a valid kernel you build a block on top of the main chain like everyone, but you also build other blocks (using the same kernel) on lower chains (that you normally consider abandoned).
The current peercoin code prevents that by ignoring blocks if the kernel has already been seen in another block. That means if you mint on multiple chains, then only your first block will be propagated by the other nodes. Your second block may still be accepted if ever another block is built on it (for example from a node who saw that 2nd block first, and built his own block on top of it). This is to prevent a network split when nodes do not receive blocks with duplicate kernels in the same order.
My proposal is to change that behavior. When a node receives a block using an already seen kernel, then the previously accepted block will be rejected (the block in which the kernel was already seen). That means all the transactions included in the block will become unconfirmed again until another block is produced, and the attacker reward will be cancelled. It will be like the attacker never sent any block. This duplicate block will be propagated to other nodes so that everyone does the same.
This will only happen if the block you reject is the highest block. You won’t reject an already confirmed block.
@sigmike interesting approach
Attacker can still create split by listening for new (not his) blocks built on top of his block and immediately broadcasting duplicate. He can also invalidate “the row” of his blocks by sending duplicates one by one. But time window available for attack shrinks greatly, also the attack outcome/propagation cannot be predicted/designed as easy as currently.
The chain with the new block will be the official chain. If I understand correctly, under the proposal any attempt to broadcast a duplicate from the same kernel will be discarded EVEN if the duplicate chain has higher coin-age consumed because the client has already seen the kernel included in the original chain. Even if the original chain is orphaned, the attacker’s previously broadcast kernel/timestamp is forever ignored by honest nodes.
Once a block has been built-upon by a new block, it can never be invalidated/displaced by a “duplicate” block using the same kernel.
[quote=“kac-, post:57, topic:1394”]@sigmike interesting approach
Attacker can still create split by listening for new (not his) blocks built on top of his block and immediately broadcasting duplicate.[/quote]
No. The block must be signed by the private key of the kernel. So you can’t build a block from someone else’s stake.
Yes, someone able to mint 6 blocks in a row can remove them. But I if someone is able to do that then he can already harm the network.
And if anyone else builds a block on top of any of his blocks in the meantime then this ability disappears.
No. The block must be signed by the private key of the kernel. So you can’t build a block from someone else’s stake.[/quote]
I think I misunderstood the remark.
If you send your own duplicate block A2 just when the network receives a block B on top of your own previous block A1, then all the nodes will accept A1 and B.
The ones who receive A2 before B will move 1 block backward and when they receive B they’ll move 2 blocks forward (A1 and B), accepting the duplicate A1.
The ones who receive B before A2 will just ignore the duplicate A2 when they receive it because it’s lower than B.