Since the network has a tolerance of two hours of time stamp error, does it mean one can try 14400 different time stamps per second?[/quote]
Yes. There are other limits involved but you can try more timestamps per second. The client already tries some previous timestamps if you missed them.
But if you try the next 14400 timestamps at time t, then at time t+1 you’ll try 14399 timestamps you’ve already tried, and only try 1 new. So you still try only 1 new timestamp per second.
If you do that it may still be a little easier to find a block if the difficulty changes a lot (because you’ll try more timestamps when the difficulty is low). But it’s probably not significant. And you wouldn’t get more reward, you’d only a part of it earlier.
Since the network has a tolerance of two hours of time stamp error, does it mean one can try 14400 different time stamps per second?[/quote]
Yes. There are other limits involved but you can try more timestamps per second. The client already tries some previous timestamps if you missed them.
But if you try the next 14400 timestamps at time t, then at time t+1 you’ll try 14399 timestamps you’ve already tried, and only try 1 new. So you still try only 1 new timestamp per second.[/quote]
Is it right? In the (N+1)th second the difficulty and the hash for the previous block have all changed so you won’t get the same hash with timesptamp=N as you did in the Nth second (when timesptamp was N). All 14400 hashes would be new compared with the last second.
And you wouldn't get more reward, you'd only a part of it earlier.
That is true. But the minters with small stakes have incentive to get a block earlier or they don't get any POS for a long time (years). Or for those who want to spend the coins that have generated coin-ages but haven't gotten POS.
Difficulty and hash of previous block only change when there is a new block, which happens about every 10 minutes, not every second.[/quote]
You are right. So when there is a new block this can work once. On average there is a 14400/60/10=24 times advantage. (14400 is the number of seconds in +/-2hr). Every stake that finds a POS block will be off for 30 days. So actually it will take 30246=4320 stakes to be able to have one exploit for every block. Nodes doing this will push up POS difficulty, reducing other stakes’ access to POS blocks by 24 times, hence weakening network security. Unless I get it wrong somewhere it seems a serious problem.
That calculation was not totally correct. It assumed anyone who does this will finish looking for a block within a second, and will repeat the same the next second. Actually he has a 14400 times advantage as long as a valid stake (unspent input). If it takes 10 minutes to try all of them, he will have a solid 14400 times advantage.
Is it right? In the (N+1)th second the difficulty and the hash for the previous block have all changed so you won’t get the same hash with timesptamp=N as you did in the Nth second (when timesptamp was N). All 14400 hashes would be new compared with the last second.[/quote]
Actually the previous block hash in not part of the hash you compute in PoS. So the 14400 hashes stay the same even if there’s a new block.
The only thing that may change is the difficulty.
[quote=“sigmike, post:15, topic:2189”]Actually the previous block hash in not part of the hash you compute in PoS. So the 14400 hashes stay the same even if there’s a new block.
The only thing that may change is the difficulty.[/quote]
Since the new kernel is found by hash(nStakeModifier + txPrev.block.nTime + txPrev.offset + txPrev.nTime + txPrev.vout.n + nTime) < bnTarget * nCoinDayWeight can’t you try 7200+600 nTimes for every prev block? Other people can only try 600 times before the next block is found, in average 600 sec. The 7200 is the number of seconds in the 2hr clock error that the network allows you to have. Maybe it is 14400. I am not sure. But anyway in this exploit basically you pretend to have a wrong system clock.
You can try, but since the prev block is not used in the hash, you’ll find the same hash for every prev block. So you don’t get any more chances when the prev block changes.
Note that txPrev.block is the block where your coins were confirmed, not the last block in the blockchain.
It is generated a few blocks after your coins are confirmed. It exists to prevent you from precalculating when you’ll be able to find a block before the transaction is confirmed. It doesn’t change over time either.
Aha that is what I didn’t get. Thanks. So the exploit only get an extra two hours. That is no big deal.
But if nothing in the expression changes except nTime, bnTarget, and nCoinDayWeight which is a known function of nTime , this means that I can calculate when in the future I likely will be getting a kernel. ???
The difficulty fluctuates around a relatively slow changing average hence can be estimated at some certainly. For a particular stake, anyone who wants take advantage of knowing roughly when the stake will find a kernel might skip minting before time is about up. This stake still contributes to supporting the network. This in itself is harmless. However if a person has many stakes of similar coin age, he could use this knowledge to spend those stakes that will find stakes far in the future, hence improve the average block finding rate for all his stakes; Or he could immediately send the stake that needs more than average time to find a kernel to himself again, if the odd to get a better time, and the compound interest outweighs the tx fee.
I am glad that in any case the impact to network security is limited.
Using Peerunity has really crystallized a question I had.
Is there a reason, technically, that you can’t “merge” coins at the same address when they reach maximum maturity? That is, if I have 1 coin in address X, and 100 coins come into address X later, those 100 coins are much more likely to mint than the 1 coin. And from a probability standpoint, the 1 coin will never mint, though the 100 coins will. So it seems like anyone who makes smaller transactions will never be able to mint, even when those small transactions reach maximum maturity?
The only solution within the current system that I see is to make a new transactions of all coins into one address periodically. This has some clear drawbacks though. Thoughts?
[quote=“Blackbird, post:22, topic:2189”]Query about minting.
Using Peerunity has really crystallized a question I had.
Is there a reason, technically, that you can’t “merge” coins at the same address when they reach maximum maturity? That is, if I have 1 coin in address X, and 100 coins come into address X later, those 100 coins are much more likely to mint than the 1 coin. And from a probability standpoint, the 1 coin will never mint, though the 100 coins will. So it seems like anyone who makes smaller transactions will never be able to mint, even when those small transactions reach maximum maturity?
The only solution within the current system that I see is to make a new transactions of all coins into one address periodically. This has some clear drawbacks though. Thoughts?[/quote]
when minting your transactions get split anyway, so you end up with small transactions which are minting
[quote=“irritant, post:23, topic:2189”][quote=“Blackbird, post:22, topic:2189”]Query about minting.
Using Peerunity has really crystallized a question I had.
Is there a reason, technically, that you can’t “merge” coins at the same address when they reach maximum maturity? That is, if I have 1 coin in address X, and 100 coins come into address X later, those 100 coins are much more likely to mint than the 1 coin. And from a probability standpoint, the 1 coin will never mint, though the 100 coins will. So it seems like anyone who makes smaller transactions will never be able to mint, even when those small transactions reach maximum maturity?
The only solution within the current system that I see is to make a new transactions of all coins into one address periodically. This has some clear drawbacks though. Thoughts?[/quote]
when minting your transactions get split anyway, so you end up with small transactions which are minting[/quote]
So, what does one do with a very small transaction? If I have 1 PPC in a transaction, what should I do?
I’m facing the same situation, and I’m just waiting to have enough coins to merge them. You should either merge that 1PPC to a bigger transaction that just minted (so you don’t loose too many coindays) or just wait to have more of these 1 PPC. Unfortunately and in any case, that 1 PPC won’t bring you enough coindays to be able to mint at the current PoS diff.
I’m facing the same situation, and I’m just waiting to have enough coins to merge them. You should either merge that 1PPC to a bigger transaction that just minted (so you don’t loose too many coindays) or just wait to have more of these 1 PPC. Unfortunately and in any case, that 1 PPC won’t bring you enough coindays to be able to mint at the current PoS diff.[/quote]
What then, is the appropriate number of coins one should have before merging at present difficulties?
I’d say somewhere around 500 is ok if you can’t have more than that. Otherwise if you can, I would advise not to have less than 3,500 coins per chunk. Because after 90 days you stop earning coindays, which also means you’ll max out your minting reward… So better keep a 15 days window during which you have at least 90% chances to mint before these 90 days in my opinion.
I’d say somewhere around 500 is ok if you can’t have more than that. Otherwise if you can, I would advise not to have less than 3,500 coins per chunk. Because after 90 days you stop earning coindays, which also means you’ll max out your minting reward… So better keep a 15 days window during which you have at least 90% chances to mint before these 90 days in my opinion.[/quote]
Hmm.
I’m trying to understand the system better, because I do legal research on crytpocurrencies. I realized, after waiting for a couple months for minting to occur, that all my small transactions (3-4 PPC) won’t ever mint. I just put em together in a larger chunk, hoping it’ll mint now. I suppose I’ll see what happens.
Just use the website I’ve liked to calculate your minting probability per amount of coins that you have for a given transaction. And you’ll see for yourself how long you have to stay connected to the network for minting to occur (yes, yes, connected to the network and with an unlocked wallet h24 with 8 connections minimum!)
Basically with 50 PPC in one transaction, you have 21.95% chances to mint if you keep your wallet unlocked within 90 days (which is also the maximum coinage you’ll reach). So… about 1 chance out of 5 that your 50 PPC mint within 90 days…
So, just increase that amount of coins up to a decent amount and wait… You can use that tool to calculate when exactly your TXs are going to stake: https://peercoinfindstakedata.divshot.io/, so it will avoid keeping your wallet unlocked h24.