Quote from: dooglus on July 03, 2015, 11:02:17 AM

Quote from: SebastianJu on July 03, 2015, 10:31:09 AM

*lol* Sounds like a currency that rewards you for NOT using it as a currency. If i would have read it without knowing clams i would think this is a scamcoin and the creators did this to become rich. Tongue

Maybe you misunderstood. Staking destroyed age, setting it back to zero. So it's not like old coins keep getting old and staking at the same time. You choose: stake, or gather age. The idea seemed to be that you could load up your wallet once a month and collect all the built up staking that had accumulated due to the age. But when staking is meant to secure the network surely you don't want people only doing it once a month. Hence the abolishment of 'age'...

Oh, that makes more sense then.

Quote from: dooglus on July 03, 2015, 04:30:54 AM

Quote from: SebastianJu on July 03, 2015, 10:31:09 AM

Thanks for the explaination. So the sets of parameters for each second are fixed. You cant try different hashes in one second. Or 16 seconds, now. Would one have an advantage when calculating hashes in advance? I guess so since finding hashes for the same second should be hard. I mean where do you take the second from? Your second can be some seconds after the seconds of other miners, so you would be late all time, not finding a block ever.

All the inputs are fixed. You can't increase your chances of finding a 'good' hash by throwing more CPU at it. You could calculate hashes somewhat in advance (though I think some of the inputs depend on recent blocks, so not too far in advance) but hashing doesn't take long anyway. The JD staking wallet checks something like 30k outputs in 4 seconds.

4 Seconds? Is that needed for finding a block each time? Given a difficulty leading to 16 seconds these 4 seconds would be huge. I mean the difference to orphan blocks or get block orphaned. Or isnt it needed to calculate a block?

Quote from: dooglus on July 03, 2015, 04:30:54 AM

src/kernel.cpp says this:

Code:

// Stake Modifier (hash modifier of proof-of-stake):
// The purpose of stake modifier is to prevent a txout (coin) owner from
// computing future proof-of-stake generated by this txout at the time
// of transaction confirmation. To meet kernel protocol, the txout
// must hash with a future stake modifier to generate the proof.
// Stake modifier consists of bits each of which is contributed from a
// selected block of a given block group in the past.
// The selection of a block is based on a hash of the block's proof-hash and
// the previous stake modifier.
// Stake modifier is recomputed at a fixed time interval instead of every
// block. This is to make it difficult for an attacker to gain control of
// additional bits in the stake modifier, even after generating a chain of
// blocks.

and this:

Code:

// ppcoin kernel protocol
// coinstake must meet hash target according to the protocol:
// kernel (input 0) must meet the formula
// hash(nStakeModifier + txPrev.block.nTime + txPrev.offset + txPrev.nTime + txPrev.vout.n + nTime) < bnTarget * nCoinDayWeight
// this ensures that the chance of getting a coinstake is proportional to the
// amount of coin age one owns.
// The reason this hash is chosen is the following:
// nStakeModifier: scrambles computation to make it very difficult to precompute
// future proof-of-stake at the time of the coin's confirmation
// txPrev.block.nTime: prevent nodes from guessing a good timestamp to
// generate transaction for future advantage
// txPrev.offset: offset of txPrev inside block, to reduce the chance of
// nodes generating coinstake at the same time
// txPrev.nTime: reduce the chance of nodes generating coinstake at the same
// time
// txPrev.vout.n: output number of txPrev, to reduce the chance of nodes
// generating coinstake at the same time
// block/tx hash should not be used here as they can be generated in vast
// quantities so as to generate blocks faster, degrading the system back into
// a proof-of-work situation.

I've never tried to understand it fully, but it looks like the author went to some lengths to make it hard or impossible to game.

Quote from: SebastianJu on July 03, 2015, 10:31:09 AM

And you said the wallet checks each of your addresses. Does this mean you can have different addresses in your wallet and you could try out each one if it creates a correct hash?

I did? I didn't mean to. It checks each *output*. You can have multiple unspent outputs per address. JD keeps most of its value split into 30k separate outputs at a single address. The wallet loops through all the unspent outputs it controls, does a hash for each of them, trying to find one that hashes low enough to stake a block.

Then i misunderstood your sentence.

So the 4 seconds are real and you meant it goes through each of that outputs (shouldnt it be inputs as long as they arent sent out?) and checks if it finds a hash? Does the output amount matter here? I mean you described rounding the amount of clams down to an integer. Does this apply to the address these outputs are on, so a big amount of clams or only to the single output? If the latter then one could get an advantage by sending the clams in amounts of 1 to a new address. The chance to find a block would be maximized?