I hope sigmike doesn’t mind that I posted this, but I felt that it’s a useful conversation for the community to see, because he does a great job of simplifying the concepts of what happens when the CPUMinter process is running. I, of course, come off as a total n00b, and deserve any ridicule that comes out of this As you’ll notice, in addition to being a great developer and teacher, sigmike, has the patience of a saint.
[13:23] Mike, am I recalling a conversation we had a couple weeks (maybe months, now) ago correctly? “When CPUMinter is running, the process is looking to solve for the next block, and if it finds a prospective match, only then does it actually check to see if the user’s wallet contains mature coins that can be used for proof-of-stake”?
[13:26] It goes the other way around: each second it takes all the available wallet coins (the ones you can spend) minus the reserve, and for each one it checks whether it matches the target difficulty
[13:28] So, let me make sure I’m clear on that. Here’s a hypothetical scenario:
[13:29] Over the past 3 months, I’ve received 4 transactions for 100 PPC each
[13:29] One 90 days ago, one 60 days ago, one 31 days ago, and the last was today
[13:30] When CPUMinter is running, once per second it’s checking to see if any of the first three values matches the current target difficulty?
[13:30] (assuming I have no reserve set)
[13:32] ben: it will try to find a kernel on all coins, but for the coins not old enough it will stop early, before the actual difficulty check
[13:32] Ok, so it would be attempting four validations per second, in that case
[13:33] depends on what you call validation, but yes
[13:34] it will stop here exactly: https://github.com/Peershares/Peershares/blob/master/src/wallet.cpp#L1261-L1262
[13:37] Knowing that the process is able to do that (differentiate between immature and mature coins), is it reasonable to expect that a new method could be added that would output a list of transactions that are currently being used in those attempts, with details like “amount,” “current coin age,” “from tx_id,” etc.?
[13:39] you mean keeping a record of the outputs that were used during the last minting and make these data available through an rpc command or in the GUI?
[13:41] or adding a new method that does the same thing as the mint thread but would not actually mint and only report these data?
[13:42] Through the GUI or CLI, yes, but the intent would be for me to be able to see what coins in my wallet are potentially going to solve a block. So if that means a report, after the last second’s mint attempt, then yes, that’s what I mean
[13:43] If it was in Peercoin first, I was thinking something like:
[13:43] $ ./ppcoind listmintablecoins
[13:44] or listmintingcoins
[13:45] From what I’m hearing from people, and from my own experiences, it’s very difficult to understand what’s going on behind the scenes while minting is occuring
[13:45] I’d rather keep a record, it involves less code duplication
[13:46] A record would be fine, if the end result was the same
[13:46] and you could also add how far it was from the difficulty
[13:47] it shouldn’t be hard to implement. The difficult part may be to make Sunny merge it
[13:47] Other than as a “nice to know,” what would that tell me? Is it predictive of how long before that input could likely match the difficulty (meaning, if difficulty was 10.8 and you saw ‘5.5’, does that mean anything from this second to the next?)
[13:50] ben: no it would not be predictive of anything
[13:54] I think it would help if I had a better understand of the mechanics. If I have 1000 PPC and have held them for 60 days (coinage= 60000) and I have 100 PPC for the same 60 days (coinage=6000), does my 1000 PPC input tx have a better chance of solving a block with minting because the search space it’s provided is much closer to the current target difficulty?
[13:55] (Completely fake numbers) – TargetDiff = 10.8M, 1000 PPC tx searches hashes that would fall into a range near that, vs. the 100 PPC tx, that has to search the whole space?
[13:56] And thank you for putting up with these questions, and having the patience to answer them
[13:57] you have more chances with the 60000 coinage tx because the difficulty target is lower than for the 6000 coinage tx
[13:58] the target is actually a TargetPerCoinDay
[13:59] I’ll have to think about that one. I’m not quite grasping how it all works together
[14:00] Thanks
[14:00] the hash you produce is random, and it must be below TargetPerCoinDay * CoinDay
[14:00] so your 60000 coinage has 10 times more chances than the 6000 to match this condition
[14:01] and “more chances” isn’t a measure of actual attempts, but a reduction in the number of potential matches?
[14:02] So, in a very simplistic scenario, not using minting – I ask you and PB to pick a number between 1 and 1000
[14:02] For PB, his guess is within the scope of 1 - 1000, but for your guess, I give you a hint and say, ‘it’s between 1 and 100’?
[14:05] 99! I cheated
[14:05]
[14:05] yes ben
[14:05] your 60000 tx has to find a random number between 0 and 60000target, and your 6000 between 0 and 6000target
[14:06] and both can do 1 attempt per second
[14:10] and the random number you pick is between 0 and 2^256
[14:11] An that’s the part that mixes me up a bit
[14:13] How does the target get calculated?
[14:13] from the time between the last 2 blocks
[14:14] I don’t fully understand the calcuation. Must be a standard math formula though
[14:14] Ok, so that’s like PoW, trying to maintain the distribution of ~ 1 per 10 minutes
[14:14] s/like/same as
[14:14] yes
[14:16] So the total search set is between 0 and 2^256 – the target multiplier “helps” both tx’s above, but it helps the 60000 one more
[14:16] So the 6000 tx always has a chance, it’s just that the chance isn’t nearly as good
[14:18] (which, now, I can see why Sunny capped maturity at 90 days; otherwise, a long-held, small stake could eventually reach a point where the chance to solve the next block would be very high)
[14:19] yes
[14:20] This has definitely been an “AH HA!” moment
[14:20] nice