[quote=“kac-, post:2, topic:3348”]
- add the previous best block hash to your PoS hash, as this will make your stake hash change as each new block is added to the chain
I think that it could reintroduce „stake grinding attack”.[/quote]
To my limited understanding, the ability of successful stake grinding relies on the high variability of the inputs being hashed. Adding the last block hash gives more variance to the hashes, seeing as they don’t remain the same through perpetuity (which is why I think you replied as you did). But at the same time, if you are reducing PPC drift down to 60 seconds, or a smaller window, you are reducing variability greatly on that front. Also if this is done in conjunction with the cap on weight I mention above, it adds another limitation to the mix for the attacker.
I think that this new cocktail could be a bit stronger than the old cocktail, but it will take more analysis.
I am mostly going by your post here:
[quote=“kac-, post:12, topic:2502”]I would make SG that way:
- Prepare stake
a) buy old minting keys
b) buy old not-minting keys and mint blocks for 16 days (64 6 hour long stakeModifier intervals)
- Create 64 tuples (stake-selected-by-modifier, signature1, signature2), signatures that give different first bit of block hash
- Brute-force this 64 bit space:
a) re-create chain w/ new signature
b) mint on top of it for next stake modifier interval
c) choose best/satisfying chain trust, remove oldest (block, sig,sig) tuple from 64 set, add new one
d) repeat from (a)
e) optimize, pray for more trusted chain, if not- take next ~bit combination and goto 3.a)
Can core-dev verify this flow? May run parallel.
Or go full-random and mix and mint till you win.
Attacker needs 7200+ outputs, to cover whole 64 bit space he needs (2^64 - 1) * 7 200 = 1.32 * 10^23 (10^8 peta) stake-hash / calc-sec, right? With time he’ll narrow his initial search space but to fight-the-random he’ll need to create computation branches from his best chains. IDK, leaving this thread until someone optimize it.[/quote]
Let’s assume a scenario where blockhash is added to the PoS hash, and timedrift is changed to 60 seconds. An attack psuedo code would look something like this:
ss << nTimeBlockFrom << nTxPrevOffset << txPrev.nTime << prevout.n << nTimeTx << bestBlockHash;
hashProofOfStake = Hash(ss.begin(), ss.end());
if hash meets target wrap it up into a new block and get the block hash without sending to network
2)
create next PoS hash, hope that you can hit the target (attack becomes less likely here)
target hit? create block and get the hash and move to the next iteration of the process
How large of a chain could you realistically create with this process? For each given time period you would have 60 hashes per utxo (as is the case with any 60 second drift allowance). The difference here is that you get a fresh set of tries each iteration. I suppose you could theoretically go through this process until you have created a good chain of blocks, but it increasingly becomes less likely each iteration.
The other question of this is whether you could insert this attack into the past, and create a chain that would be re-orged to. I tend to think it would be much more difficult, because blocks will be coming in much more tight on the main chain so it would be extremely hard to create an alternate chain with as much chain trust.