So the official client is only minting with one hash per second? Doesn’t this mean I could make a “minter” program which hashes as fast as it can? What about Peercoins energy efficiency if I do this? I would waste more electricity this way.
So the official client is only minting with one hash per second? Doesn’t this mean I could make a “minter” program which hashes as fast as it can? What about Peercoins energy efficiency if I do this? I would waste more electricity this way.[/quote]
That is what I remembered. It’s a low number for a low difficulty to meet the 10min/POS-block target.
If you hash multiple times in the same second, you’ll get the same hash each time. This is because the hash is based on static data + the current time in seconds.
Wow, that is an impressive idea. Hashing static data + Time means one block per second. Nevertheless, I could use a 10 second window for my timestamp to generate 10 hashes a second, right?
Let me try to explain Multiple Stake Minting:
If there are two blocks with the number 10,000 found within seconds of each other, both propagate the network. Now, other minters can not know which of these two blocks will be in the longest chain. The longest chain is decided once one fork finds block 10,001. Other minters SHOULD mint both chains to get the best chances on getting a Proof-of-Stake reward.
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=“lacksfish, post:39, topic:1394”]Let me try to explain Multiple Stake Minting:
If there are two blocks with the number 10,000 found within seconds of each other, both propagate the network. Now, other minters can not know which of these two blocks will be in the longest chain. The longest chain is decided once one fork finds block 10,001. Other minters SHOULD mint both chains to get the best chances on getting a Proof-of-Stake reward.[/quote]
That’s what was discussed above.
You have the same chance to find a block on each chain. So you don’t get more chances on finding a block.
What you get is only more chance that your block will end up in the main chain instead of the orphaned one, at the cost of destabilizing a little the network.
In the other hand if you don’t do that and you end up having minted on the wrong chain you only loose time, not reward. You’ll get your reward later (along the new accumulated reward).
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!