Here is an alternative idea to leading zero bits for constructing a blockchain.
Now that the "author" of the warrior has "won" the "corewar" and has a warrior that can do 10 points better, only this author is allowed to advance the blockchain by +1 block. The author's private bank account key could be used to sign this new block and then this block is added to the chain. Other peers can determine the block is valid by using the public key of the bank account to verify that it was indeed signed correctly.
Thus constructing a leading zero bits hash might not be necessary.
Interesting idea.
This author/bank could generate multiple of these blocks, creating multiple subchains and such, but eventually one of them will probably become the largest/longest one/advanced one and be the best/valid chain.
One problem with this could be if private/public key of bank account changes... hmmm..
One possiblity could be to then later hash the block, to create a linked-chain of hashing, so that it cannot be changed easily without changing the rest of the chain. Verifieing that the block was genuine is then simply done by computing hashes only when blocks downloaded from clients, for new peers. In this case author/bank account and block is not checked to see if it matches. Only when peers receive a new block which they have not yet seen is it checked, this might be an oxymoron though =D cause chain should probably work during downloading as if the block was generated... not sure if this can simply be ignored... probably not... unless peer relies on existing peers to compare hashes and make sure it does hash to the correct chain which is kinda what hashing is for anyway, don't need leading zero bits for that.
What is needed is to know if warriors indeed beat the previous ones, however once these warriors are collected it can be used to re-write the chain and create new transaction blocks with different hashes and even producing a longer hash.
The funny way underlying blockchain seems to solve it is to store hashes of bank accounts and then concatenate then and compute a hash over it. Now that I see it written here don't really think it's too safe, since a longer chain could be produced by simplying following this method, though it does require also computing a blockchain which has same bank account total hash, something like that. and these hashes are leading zero bits.
To make these hashes attached to warriors somewhat, the simulator has to compute hashes as the warrior is executed. This will make it somewhat computationally intensive to re-compute this, but still not too much re-computation work, to re-compute such chain. So security would now depend on the last warrior, and even if this one is found a new chain can be generated which would equal it.
So this design does seem somewhat weak and might need leading zero bits to prevent re-writing chain easily... hmmmm.... though computing a block could be made somewhat computationally expensive by trying out all warrior positions, but at a certain point a large enough mining farm could catch up. Trying out all p-space computations/variations is computionally almost impossible to compute. Some random positions could be used by doesn't really matter much since new chain can be somewhat computed. Unless perhaps positions are based on genesis block, and then the previous block to that etc... but again this would kinda dictate starting positions to some degree... though it has to be somewhat random and transaction data could/would be used to see this random generator, though re-writing this random data would then allow to produce a new chain, quickly rivalling the existing chain.
One complex idea could be to somehow use difficulty to determine how many additional p-space variations would have to be calculated, though this would only really work if warriors actually used p-space and this is not garantueed so this is very weak.
Somehow the data/chain must be protected against modification, and this protection must become computationally more expensive over time as more peers join and the chain grows. Once a warrior's code is known it should not be possible to re-use it again to generate different blocks herein lies a bit of a problem.
I think the problem is already solved, since only the author/owner of the warrior could re-sign blocks... to become the new fake author would require to re-compute the leading zero bits associated with the warrior and bank account. While theoretically possible, this could be detected and disalllowed, the database can keep track of which author published a warrior first and take this into consideration to compute a bank hash, if dates or ownership is changed this would produce an invalid bank hash and can probably be detected in the blockchain that currently exists.
So re-creating a bank account chain is not as easy as it first seems, since not all warriors can be owned, recomputed assuming some authors calculate a strong warrior leading zero bits hash.
So this feature of this bitcoin hash design does offer some good protection against changing data. It's a bit of a cheesy work around though, to let authors compute these leading zero bits instead of mining farms and such but I like this, cause this does give peers/persons/people some more chance of actually computing a block on their own private time, in combination with finding a good warrior, which is perhaps more difficult than calculating simply "dumb" leading zero bit hashes... though that is "so" simple it can be done by anybody so in that sense it is kinda fair, but again not because of these farm.
With calculating warriors it becomes a bit different ball game and "smarts" of evolvers comes into play... so then more smarter/intelligent people would maybe win this, which might kinda suck because this chain was kinda ment to allow everyone to mine some blocks, for now I can only hope that smart evolvers would be shared, and that it does become a bit of a luck thing with finding a good warrior. Kinda funny.
(I think it's a bit safer to first hash everything and then sign the hash with a private key to prevent any re-ordering of data/messages, maybe not required if hashes are linked later anyway, but can't hurt to do that:
https://crypto.stackexchange.com/questions/12768/why-hash-the-message-before-signing-it-with-rsa).
What could be interesting about this design is that it might even be stronger than bitcoin itself, since mining farms don't really have everybody's private key, and these private keys are now necessary to construct a valid blockchain, at least for growing it as a very minimum. Perhaps it's enough to encode the public key with the blocks themselfes, but this would then again probably allow forgeries by simply replacing the public key with something else.
Thus to prevent this from happening the bank account would probably need to calculate as follows:
leading zero bit hash = hash( warrior code + author name + public key )
To protect the public key from simply being replaced with a forgery.
Chain's strength is then kinda the strength of the individual author's leading zero bits calculations, which could funny enough be kinda weak.
Might have to come to the conclusion that there is no way around "leading zero bit hashes".
Though original idea was to used warrior's score as for example indicate what the target value should be... but then hashes would still need to be computed as well as warriors... and this kinda bores me if asics can compute hashes faster, then joe average... wouldn't really make the chain much stronger against forgeries that's the main problem.
For now I can only come to the conclusion that underlying blockchain technology should probably remain functioning the way it is and to still make this project work/a reality a cheesy additional check/constraint/requirement could be added that coins are only rewarded if previous warriors are beat/fought against and produce a certain score that beats the previous best score, also to prevent cheesy copies, only if the warrior produces +10 additional points then previous warrior coins are rewarded, this could be cool
.
Thus everything else can stay the same... cheesy, simply perhaps stupid, but maybe it will be fun !
