If we create a hash for our UTXO, and once we have generated a successful modifier, can predict when this UTXO will be able to stake… What is stopping an attacker from figuring out when they will be able to use a group of their UTXO’s to successfully confirm multiple blocks in a row?
It seems to me, and a few other people on HyperStake, that this is too predictable.
I will begin experimenting with adding the last blockhash in the chain to the PoS hash. This way your hashes would be modified each new block that is added to the network.
Does anyone have any thoughts about this? Do you like the precomputation that can occur? Or do you agree that this is a security concern?
Good questions indeed.
I wonder how to force a fork in the ppc-pos chain so a double spend attack can occur? anybody?
[quote=“thehuntergames, post:2, topic:3344”]Good questions indeed.
I wonder how to force a fork in the ppc-pos chain so a double spend attack can occur? anybody?[/quote]
Correct me if I am wrong, but there is not code that makes sure that x amount of PoW blocks come in for every PoS block right? I don’t think you would have to force anything. Lets say I have a lot of UTXO’s that I calculate will all be eligible to stake 50 days from now, so long as PoS difficulty is less than 20 (I have no idea what ppc diff actually is). Then 50 days from now, lets say the diff is 10. I could pop out a succession of PoS blocks onto the chain so fast that no PoW blocks would have had a chance to hit the chain yet.
If I had double spent on some of these, would these end up being denied when the next blocks start coming in?? I thought I had read that in PPC the PoS chain takes reorg preference over the PoW. Not sure if I am remembering correctly or not.
Let continue the thought experiment.
Suppose I ve managed to collect a bunch of unspent outputs. And from that collection I ve calculated that on 5th of Nov between 12:06 and 12:19 I’ll be able to pop 1000 pos stakes into the network. (Must have a lot of coins to pull this off, not 50% but a lot none the less)
What it causes is as the preferred pos target is 10 minutes, the pos difficulty will shoot up to countermeasure the 1000 pos stakes released in short timespan. The pow target, prefered to be at 120 min with 10+ pos stakes in between, stays unaffected I think here.
So in contrast to the time drift attack as discussed in the other thread, the pos difficulty shoots up, not down. This upshoot will prevent others from minting their stakes as the then current difficulty may exceed the min difficulty of say 20. (Need to collect thoughts still what this means…)
That said, I still dont know how to double spend coins unless you can force a chain fork?
–update-- How is it possible to pop so many pos stakes into the network btw as the pos difficulty adjust upwards after each pop? my answer: very unlikely
How do double spends occur for any coin? Honestly I am no expert with this, but I know that coins have double spends (including PoS only coins), and that there is no modification to the code needed to do this. I haven’t researched or tried double spending.
--update-- How is it possible to pop so many pos stakes into the network btw as the pos difficulty adjust upwards after each pop? my answer: very unlikely
You would have to find a series of utxo’s that would be good under a certain difficulty, lets call it 20. If the difficulty at the time of attack starts at 1, you could have plenty of room to submit blocks until difficulty exceeds 20. Also depending on when your utxo’s hashes meet the protocol, they could be in fact exceed the target spacing and call for difficulty to adjust downward.
Edit - above when I say “no modification to the code” I mean to the peers code, who will see the attack as valid. Obviously the attackers code would be modified.
Lets assume you stake at a rate of 1 pos block per second.
GetNextTargetRequired function will increase the current diff with factor:
s/(1009*600)= 1.0013445655764783614139411959035
if theoretically speaking you do this 5 minutes on end the diff becomes ((1007602)/(1009600))^300 = a factor 1.5 times the initial difficulty. So 10 ->15 after 5 minutes, so yeah it is possible. Others who had expected to mint at e.g. 13 on these days will be left out.[/s]
edit–
Need to correct myself:
((1007600)+2)/(1009600)= 0.998021143
the target space becomes this much smaller to make it more difficult to find a match.
if done for 5 minutes on end, the target drops to a factor 0.998021143^300=0.55 times the initial target.
(The method to get from target to difficulty involves converting to compact as a intermediate and will be left out here to keep it simple…
in short: Floating point representation of difficulty shows how much current target is harder than the one used in the genesis block (difficulty_1_target).
difficulty = difficulty_1_target / current_target
= shows an inverse relation to its target
)
Like wise if the actual spacing is 2 hours the next target becomes
((1007600)+14400)/(1009600)= 1.021803766 larger to make it less difficult next time.
However, dont see in this experiment how to do this successively
–update 2
To create a fork, do the following;
- collect a bunch of outputs that will stake in a future timespan X
- have a private network of nodes that dont broadcast new stakes
- When X come due, stake those coins with your own nodes without broadcasting
- meanwhile, double spent coins on the normal chain was well as your own forked chain
- release your forked chain, if it is the longest coin age --> profit
[quote=“thehuntergames, post:6, topic:3344”]Lets assume you stake at a rate of 1 pos block per second.
GetNextTargetRequired function will increase the current diff with factor:[/quote]
Remember that submitting one per second does not mean that the timestamps are 1 second apart. I could be submitting blocks up to two hours in the future, and the difficulty adjustment code is reading the block timestamp not your system clock.