This is where my technical lack of confidence shows.
Each unspent input of 1BTC or more has equal chance to solve next block.
Each unspent input of 1BTC or more has equal chance to solve next block.
You mean unspent output (it isn't an input until spent)?
This forces consolidating your wallet into a small number of coins.
Quote
Miner should be low on resources. It should sleep most of 200 sec.
Hash sha256(input+last block). See if miner is closest to 0000. Announce block.
Accept PoS from network only if 200 sec passed.
Hash sha256(input+last block). See if miner is closest to 0000. Announce block.
Accept PoS from network only if 200 sec passed.
You could have a difficulty like the main chain.
I like the 1 second per hash system from proof of burn.
Hash(unspent output-hash + hash of block 1024 blocks after output was added to the chain + timestamp) / (Value in BTC)
The timestamp would have to be less than the most recent POW block and counts in seconds.
By diving by the value, a 2 BTC output would generate low hashes at twice the speed of a 1BTC output.
The delay of 1024 means that the seed for the hash is effectively random. It also means that you can't try to strategically have your transaction included in different blocks in different forks (unless they are massive).
For proof of stake, you also need to make sure that stake can't be used on 2 forks. Something must be "at stake" when you try to get a block.
Once you use a particular timestamp for your output, you can't use it again.
With your rule, someone can use an output on 2 different forks. This means that they aren't actually committing to either fork.
With POW, if they try to build a block on 1 fork, they are committing to that fork. If the fork loses, they lose their electricity etc. from mining. This forces miners to make sure that they are on the longest fork.
For POS, they has to be a way to apply a penalty if a user mines on 2 forks. Clients would monitor the POS blocks on both forks, and if you broadcast a POS block for a fork and then "double-mine" by broadcasting a block on another fork which uses the same output, then there is some kind of penalty.
For example, you might lose your output.
Once 1024 blocks are built on top of your transaction, you can compute when you are going to have low hashes.
This means that you would be able to work out when to connect to "spent" your high quality POS hashes.
