Correct me if I am wrong, but if you stake after 90 days, the output wont split up in two outputs, it stays within 1 new output. So there are no dust outputs
We definitely need a technical paper about PoS minting. I was not even aware of this, not sure new starters are too. This is not described in the whitepaper. I’ve found where it is defined in the code: https://github.com/ppcoin/ppcoin/blob/master/src/wallet.cpp#L1217 and https://github.com/ppcoin/ppcoin/blob/master/src/wallet.cpp#L1311-L1312
So yes, you’re right.
e.g.
1099.88840300 becomes 1104.56840300 after a mint
[quote=“thehuntergames, post:43, topic:2189”]e.g.
1099.88840300 becomes 1104.56840300 after a mint[/quote]
Yes, you’re right. So actually that could be an incentive to mint at D+90. Because merging rewards consumes at least 3-4 coindays (the coindays they earned when they were in a locked state)
90 days might actually the optimum for small holders --> max chances to mint, non-split transaction. But for big holders, their optimum might be around 30 days, because they don’t necessarily need to merge their rewards, and their incentive is rather to max out the compound interest.
Yep IMHO this is wiki material
shameless plug>>
One strategy I like is to use findstakejs and plan your stake at 90 days optimally (and run a peerbox as full node on the side)
Yes, so far lesson learned:
- Minting process can only start after 30 days of coinage.
- Minting coinage is maxed out after 90 days (0 day <-can’t mint-> 30 days <-minting probability increasing-> 90 days <-minting probability reached its max-> infinite). Which means that the minting process won’t consider more than 90 days of coinage even if your coins have 365 days of coinage for example.
- Minting is predictable and not random (c.f. findstakejs.peercointalk.org) --> For a given transaction, you can calculate the maximum network PoS diff over time for your transaction to be able to mint a PoS block. Whenever this PoS diff is higher than the current network PoS diff your Peercoin client can mint a PoS block.
- PoS blocks can be rejected (orphans) if several people mint a PoS block within a given window (2 hours also called timedrift). Only one (the chain with longest coin age) will be accepted.
- Minting splits the transaction in two if coinage < 90 days (this behavior can be avoided by customizing your Peercoin client: ??unsure if true and if blocks will be accepted??)
- PoS block reward is 1% annual. This 1% is factor of your coinage, and is not maxed out.
- A transaction that just staked has its coins locked for 520 confirmations (3-4 days).
- Merging transactions, spending coins, etc. burns coinage (resets it to 0).
- PoS reward is directly added to your transaction which staked (if this transaction is split in two because coinage < 90 days, the reward is equally distributed to both resulting transactions).
PoS blocks can be rejected (orphan) if several people mint a PoS block at the same time. Only one (the one that reaches the network first) will be accepted.
May be it is not a matter of first but the chain with longest coin age wins
Ah! Ok thanks 
gonna edit this.
and this Cryptoblog - notícias sobre bitcoin e criptomoedas!
if a POS kernel is found by one utxo many small utxos in the same address will be combined together
Thats great to hear from you about minting so much…thanks Ben
Hi everybody,
I have tried to make a nice diagram describing peercoin PoS mechanism:
It’s probably full of errors or inaccuracies. Feel free to correct me.
Diagram in HTML format (with clickable links and zoom buttons)
Cross posted from here
EDIT: updated thumbnail
Nice graph mably. small suggestion - coinstake also has coin age as calculation input.
Thanx mhps for your feedback. I have updated the diagram with a new block linking to the CreateCoinStake method wiki page.
I 'd like to retry to give a description for GetNextTargetRequired
The function returns an target in compact form.
For the next pos target, the nTargetSpacing is always set to 600 seconds. |S|…|S|
Depending on nActualSpacing which is the actual seconds between 2 blocks of same type, a new target is calculated with the following:
int64 nInterval = (7 * 24 * 60 * 60) / nTargetSpacing;
bnNew *= ((nInterval - 1) * nTargetSpacing + nActualSpacing + nActualSpacing);
bnNew /= ((nInterval + 1) * nTargetSpacing);
where it should be noted that division with whole numbers are floored in c++.
For the next pow target, the nTargetSpacing depends on how many pos blocks were chained in between 2 pow blocks:
0 pos blocks -> 2600 seconds |W| |W|
1 pos blocks -> 3600 seconds |W| |S| |W|
2 pos blocks -> 4600 seconds |W| |S| |S| |W|
3 pos blocks -> 5600 seconds …
4 pos blocks -> 6600 seconds …
5 pos blocks -> 7600 seconds
6 pos blocks -> 8600 seconds
7 pos blocks -> 9600 seconds
8 pos blocks -> 10600 seconds
9 pos blocks -> 11600 seconds
10+ pos blocks -> 12*600 seconds
Update:
Upon further reasoning, if lots of asic miners were to suddenly switch to ppc from btc overnight. The nActualSpacing would drop but nTargetSpacing would drop too due to less pos blocks. Vice versa, if they lost interest and switch back to btc nActualSpacing would increase but so would nTargetSpacing.
This could be interpreted as a weakening self calibration. This in contrast with the pos retargeting where nTargetSpacing is constantly set at 10 minutes which results in stronger self regulating signals.
[quote=“thehuntergames, post:54, topic:2189”]I 'd like to retry to give a description for GetNextTargetRequired
The function returns an target in compact form.
For the next pos target, the nTargetSpacing is always set to 600 seconds. |S|…|S|
Depending on nActualSpacing which is the actual seconds between 2 blocks of same type, a new target is calculated with the following:
int64 nInterval = (7 * 24 * 60 * 60) / nTargetSpacing;
bnNew *= ((nInterval - 1) * nTargetSpacing + nActualSpacing + nActualSpacing);
bnNew /= ((nInterval + 1) * nTargetSpacing);
where it should be noted that division with whole numbers are floored in c++.
For the next pow target, the nTargetSpacing depends on how many pos blocks were chained in between 2 pow blocks:
0 pos blocks -> 2600 seconds |W| |W|
1 pos blocks -> 3600 seconds |W| |S| |W|
2 pos blocks -> 4600 seconds |W| |S| |S| |W|
3 pos blocks -> 5600 seconds …
4 pos blocks -> 6600 seconds …
5 pos blocks -> 7600 seconds
6 pos blocks -> 8600 seconds
7 pos blocks -> 9600 seconds
8 pos blocks -> 10600 seconds
9 pos blocks -> 11600 seconds
10+ pos blocks -> 12*600 seconds[/quote]
Thanx thehuntergames for sharing this.
Added a link to your post on the GetNextTargetRequired wiki page: https://wiki.peercointalk.org/index.php?title=GetNextTargetRequired_function
[quote=“Blackbird, post:34, topic:2189”][quote=“mhps, post:33, topic:2189”]First remember that minting is unspent output (utxo) based, not address based.
A utxo’s ability to mint in a unit of time maxes out at 90 days. But if you have more coins in the utxo, the ability is proportionally bigger. So having more PPCs in a utxo still helps.
If one utxo in an address finds a block, your wallet will mop up all small utxos in the same address and use them to form the minting output (with a max). This helps to collect small changes and dust in your wallet. So it helps to put your little pieces in an address that has a big chunk of utxo. You might lose privacy in doing so because the blockchain will show that all these pieces belong to the same person.
I remember kac- or mably or peerchemist proved that you can merge small changes and dusts to a found stake from a different address actually. It needs some work.
If the minting output is too big (currently 100 PPC ish) the output will be split to two so that they can mint separately, adding security to the network.[/quote]
Aha.
So, work with me here. If I say, put 50 PPC into an address on day 0. And between Day 0 and Day 90, I also add some other smaller chunks of PPC, say 3-4 PPC. If on Day 120, the 50 PPC mints, and there’s 5 PPC in that address that was added on Day 30, that 5 PPC will also mint? Am I correct in that?
So for “smaller” minters, the key isn’t necessarily to merge all your PPC into one transaction in one address, but to have at least one transaction in one address that’s large enough to mint, with smaller transactions permitted in the same address.[/quote]
Could anyone clarify for me if my understanding I posted above is correct?
relevant: https://www.peercointalk.org/index.php?topic=2869.0
and the coinstake tx in question https://ppc.blockr.io/tx/info/1f08a44d9a7dea031f23659a81eb5581874898dc22378e741483d9c0167860cb
so yes you are correct, but i do think 50 ppc wont cut it unless it’s 1 in a million chance of minting. Better try 1000 ppcs
[quote=“intergalactic, post:57, topic:2189”]relevant: https://www.peercointalk.org/index.php?topic=2869.0
and the coinstake tx in question https://ppc.blockr.io/tx/info/1f08a44d9a7dea031f23659a81eb5581874898dc22378e741483d9c0167860cb
so yes you are correct, but i do think 50 ppc wont cut it unless it’s 1 in a million chance of minting. Better try 1000 ppcs[/quote]
Sure, but small coinholders don’t have 1000 PPC.
Oh, btw. You don’t necessarily need to be a full active node to mint. Not even have 8 active connections to the network. You can mint blocks with only one connection to the network. The only requirement is that the node(s) you’re connected to spread(s) your block across the network to others nodes (as much as possible). Ideally, if you manually specify your client to connect to a trusted full active node that should be enough.
Is this still true? Not required to have 8 or more than 8 active connections, only need 1 node to help spread the block?