According to the prediction of findstake that you made, one of my stakes should mint a block today. Before the time was up I ran peerunity, a live block explorer, and a clock in front of me. Exactly at the time findstake predicted, to the second, the transaction page of peerunity showed that I minted a block!
Wow you are my hero, kac-! ;D I have been having peercoins for more than a year, minting on and off, and have been running peerbox non-stop since August. This is the FIRST time I find a peercoin POS block – in front of me no less. Tip on the way!
edit:
After a closer examination of debug.log, I find that it was my peerbox that found the block, because its clock is a little faster than my laptop’s. Good job both kac- and peerchemist!
I’m surprised that more minters aren’t using findstake. It seems to me like one of the biggest breakthroughs in making minting convenient and safe, even more so than cold minting. Is there some way to make it more available to people? maybe integrated into the Peerunity minting tab?
Is it possible to use findstake, to simulate spending coins to addresses in such a way that it would be possible to run through enough simulations in order to calculate the pre-conditions required to launch a highly likely to succeed attack on the network, using an amount of coins, so small that the attack would be feasible?
I have wondered about the attack scenario too, maybe kac- can clarify. I imagine it may be at least possible for massive holders (those already capable of double spends) to use findstake to coordinate their stakes and see in advance when an attack is possible.
Though even if attacks are a concern, increased awareness of findstake may still be beneficial if it results in more participation and raised difficulty, or prompts Sunny/sigmike to make any security changes in response.
I’ve just glanced at the source code I seen something about kernels and also a stake modifier or something. I’m still to ignorant to understand things here, but I guess that “something happens” when you move the coins that is out the attackers control, so that the attacker really first have to move the coins and then see what went into the kernel? The source code says that “he purpose of stake modifier is to prevent a txout (coin) owner from computing future proof-of-stake generated by this txout at the time” and I just want to make sure that you’ve not found a workaround to this?!
Yes. Sync. check-pointing is still needed. Peerchemists Peerbox and coldminting and findstake excellent ways to help with this.
As a wanted to learn the go language, I thought I could try and port this findstake go-script to javascript.
After a long day it is still unfinished as I havent tested it properly.
Many questions remains as to where the data needed to calc the doublehash is to be retrieved from (bkchain.org/ppc/api/v1/?) For example, I ve never heard of StakeModifier before, so if others could chime in on github and get this free tool available as an alternative to peercoinposcalculator. :))
progress update:
although https://github.com/jointhepartypooper/FindstakeJS/ far from finished,
you could try it out already with the data that is available here in a readable json format till block height 142000:
FindStakeJS is going strong. ATM working on a nodejs web backend, as there is that same-origin policy browsers have. Also, the backend will have a leveldb backend, so in the end it should be able to sync its data with the blockchain.
ATM working on filling the leveldb database, but I was just wondering:
hi Kac-,
Would it be possible for you to generate another db with a higher MaxBlockHeight?
If it is no biggie to generate another one, I can parse this into the leveldb for nodejs, so the initial db that comes along with the second release of findstakejs will have the records of unspend tx till say 1 january 2015.
progress update:
although https://github.com/jointhepartypooper/FindstakeJS/ far from finished,
you could try it out already with the data that is available here in a readable json format till block height 142000: