Topic: [ANN][CwC] Corewar Coin (Cancelled ! =D) (Read 776 times)

Because of complications with the idea of hashing and minting coins based on results of fights and perhaps also other complications, this project is cancelled and the domeins are cancelled/revoked and will be gone or back up for grabs at the end of 2023 ! =D

Maybe in the future I will return to this project, but not for now...

Tuesday 4 september 2018:

Since underlying blockchain tech is probably insecure I will have to re-invent blockchain technology a little bit so that it can do what I want and is a bit more secure than this underlying blockchain tech.

Exact details will remain secret for now.

Different courses of action could be taken:

1. Either modified exiting tech to make it more secure, this would require a data structure change.

or

2. Write my own Crypto Coin System.

This system might not have the warriors in it though or maybe it will, but it might be better to create two coin systems, one traditional system without any new concepts like warriors, and then later the corewar coin system.

Approach 2 will take much more time, but I think code quality and performance of coin and security will be much better. So I may try approach 2, though approach 1 might be quicker but requires a massive re-write. Might also try approach 1 to safe some time, this could be interesting, but might also be a waste of time if some issues with this code remains... will have to think a bit and experiment a bit which approach I will take, maybe some kind of hybrid approach... integrating some parts of it's code into mine !

(I could also start a project to prove current underlying blockchain is insecure, this would require a bit of computational power that others would have to provide, it may also have to be attempted a few times in case underlying blockchain protocol changes, not sure if people want to help out and proof that it's insecure, there could be some rewards in it if you sell the overtaking blockchain coins fast on some exchange, not sure if this is legal or illegal but it's a bit nasty isn't it ! )

Bye for now.

I do not understand much about this project. how many dollars have been collected? why is there so little activity? why no news from the manager?

Saturdau 1 september 2018 I think by logic reasoning I may have found a serious weakness in the underlying blockchain technology, it has something to do with "the future" that's a hit for the problem potentially a devastating problem which may require abandoning that technology or modieifing it as well as other coin systems, throwing away data might still be possible at some risks, however it would require the hashing to be done slightly different in a two layer like fashion, satoshi almost discovered this I think but he couldn't quite right get his fingers around it, seeing his double sha256 hashing though that might just have been out of security reasons, probably yes, but there is something to it if it's done a bit different (This problem has also be sent to the main developer of underlying blockchain technology, not sure if I will ever get a reply on it, maybe yes, maybe not, for now I am guessing no, cause he may also not know a solution if the problem is real =D and it's a bit of a tedious problem/hack to try out, but definetly possible to try it out.).

Thursday 30 august 2018 some experimental code was written and tried out to examine how to travel/traverse back in time/through the blocks/blockchain of underlying blockchain technology. This will be necessary since I plan to store warriors on the blockchain only for now. However at first this may seem like a sad/bad idea since the blockchain is only a temporarely 100 blocks, eventually these block's headers will end up in the account chain/bank as well, so that should give users some oppertunity to examine what previous warriors were generated. I am not sure what happens if an account block is updated. Perhaps it's block's header/operation block is overwritten. I will have to ask some questions about this, perhaps I will get an answer this will hep me somewhat to develop faster, otherwise I will have to investigate myself further. The experimental code worked flawlessly since it was based on some pre-existing code, so this was nice and easy to write/adept.

Friday 31 august 2018 Ranked season 10 of World of Warships a bit boring, it's the same Tier X as last time

I will probably continue working a bit on CoreWarCoin cause I find it a lot of fun and it's starting to get a bit interesting. A second attempt was made at integrating the core war simulator v0.10, but eventually decided it's time to work a bit more on a more recent corewar simulator v0.12 and to use conditional compilation to filter out code pieces like throttle, visualizer, soundalizer/audio and other unwanted code elements for evolving/corewarcoin and other speedy reasons/applications. There were some slight code differences and probably some small bug fixes in v0.12 so I think it will be better to use v0.12 and finally maybe unite some pieces of code in v0.13 or so which feels like a bad version number LOL but it gonna be pretty great, after which some additionally streaming functionality can be added to v0.14 for warriors.

I am not yet sure where to perform warrior battles/score calculations inside underlying blockchain, I may have to experiment with this, or perhaps ask underlying developer where this could best be done, but for now I think I have a hunch where it can be done so will not yet ask, might do this later if experimentation fails or produces bad/poor results/performance.

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 !

Sunday 26 august 2018:

I have some security concerns about the possibility of "replaying" found/strong warriors. This appeared to be a possible attack on koth.org which had to be resolved manually/by human hands.

Found/strong warriors could be used to re-write chain history. One possibility would be to make corewar settings random and contents of core linked/chained to previous cores.

Warriors might even be required to use instructions from these cores only as to increase linkage and difficulty of finding suited warriors.

I would still be concerned that strong warriors could be re-encoded into these randomized cores so it's not a true protection against replay attacks.

It would also produce weaker warriors, since evolvers would have little time to evolve stronger ones.

Weak warriors is undesirable for me personally though.

I may have to come to the conclusion that corewars is not really suited for integration with blockchain technology and thus I may have to cancel this particular project.

Though I might still start a clone of underlying blockchain technology and then make some other adjustments lol. But this would be a bit cheesy lol but could still be good =D

For now the coming weeks I am going to play some World of Warships ranked for maybe some inspiration ! =D LOL. This will take a month or so, after which I may continue thinking about this project if there is a way to do it more securely, I am starting to believe there is no way to do it really well, so this may be the unfortunate thruth. I could still go forward with it, but then it would be very risky, and then sometime in the future it might be "hacked"... don't really want that... so better not to start something that might be hacked like that in future

Ok after playing a few minutes of World of Warships I think a possible solution might lie in the "difficulty calculation". One idea could be to require new warriors to earn significantly more points than the previous one.

For example always +10 or +100 whatever makes sense, this is a bit trial and error perhaps not sure what exactly makes sense or what would be too difficult. This may solve the "replay attack" in an abstract way, since modieifing warriors slightly would not be enough... it would be easy to make copies of warriors and change some instructions to make them look unique, but to actually make them perform better which is what peers should be rewarded for is not easy... so this might be a nice solution... at a small risk that it might take some time before a newer/strongest warrior is found !

This may introduce the risk of blockchain getting stalled/hanging... no more new blocks found, to solve that problem there could be a "fallback" mechanism, where the old system of hashing with leading zero bits is used.
If no better warrior is found the system falls back to hashing with leading zero bits, until a better warrior is found. Does sound like a nice solution at least for keeping it going. One possibility is to only allow transaction fees in these leading zero bits blocks to keep focus on finding warriors. Re-writing history with these leading zero bit blocks might be a bit difficult since competing these will also be very difficult but in future might be easier... Also to determine which chain wins, the chain with the most/better warriors should win in this case, followed by the chain where equal number of warriors reside with equal winning points and finally most work done on hashing from the last warrior onwards or so, though this would allow a somewhat re-written compressed chain... with warriors only at first, and then hashes... but eventually the hashing chain should win out... so seems like an ok solution... might come up with a different solution though to keep leading zero bits out completely.

Alternative solution might be that only when 5 minute time has been exceeded, the previous warrior might be used in the new block... however with a little twist... original publisher of warrior would then get the coins =D so he may become a rich bitch ! =D Little bit unfair but maybe not... good incentive for people to find better warriors, think this is gonna be cool ! =D

This reintroduced problem of warrior distribution and quickly copieing once elses warrior and re-distributing that as fast as possible... again random core with random instructions based on author name as random seed might help with that... basic idea as described above but might make warrior weak again... unless this idea is restricted somewhat a weaker version of this idea, where perhaps all instructions are allowed, though the core is still fed with random instructions to maybe make it a bit more difficult to re-produce the end result score based on corewar filling with author name as seed. Changing this author name/bank account would then maybe not make the warrior work as well as it would otherwise have... not a too bad idea... doubt it will work well in practice, but could be tried, to offer perhaps some protection for authors... if core is seeded always the same author could try and optimize warrior for that and indeed use some instructions from the core, but this might tie the warrior too much to this specific core setup and this is again not really what I would want... I want general/generic strong warriors, not warriors optimize for a certain core fillings and such hmmm... Also encryption of warriors come across my mind and then only later revealing the key, but again this would make it a bit difficult to determine which chain is longest/best and such... by the time key is revealed a better warrior might have been found so a bit risky, though that second warrior faces some problem of revealing itself.

One idea could be to only reveal warrior once enough peers have acknowledged it's receivement, then it's decrypted, and evaluated to see if it meets certain criteria... system could process warriors on a first come first serve basis... however this also prevents problem of "warrior spam"... congesting this queue, this could be a valid attack against corewar coins, since it takes some time to evaluate a warriors performance.

This introduces problem of "what if decryption key" is not provided.... time would have to expire after which next one is tried, but this could be an attack vector...

I think I just came up with a solution for this problem:

Warrior + Author name/bank account is hashed with leading zero bits, by author itself, so it can pre-computed this before submitting it to network... this should give network some time to distribute it around, before the hash is recomputed... perhaps not a super good solution since massive factories might be capable of re-computing it fast and replace author... but it does give author some method to calculation some protection, it's then up to author to decide how much computation/leading zero bits is enough for him

Wednesday 23 august 2018 and Thursday 24 august 2018, experimented somewhat with refactoring underlying blockchain technology and tests in general.

Tuesday 21 august 2018, I investigated the usage of Code-to-UML tools. Delphi Enterprise is best for this, it has two usefull diagrams: class diagram and sequence diagram for a method. There is also a nice youtube video explaining this from 2017: https://www.youtube.com/watch?v=n7Jm5loU_QY this can help at understanding what the code is doing somewhat. Other tools cannot read pascal/delphi as well, crash a lot or cannot make the relations properly. One tool was kinda interesting IBM Rational Software Architect for it's "sketching" feature. Kinda worried if something like that exists and it does... pretty cool, untried but there is a nice youtube video of that as well. For now I am sticking with Delphi as usual =D I will probably play around some more with the sequencing diagram. Both diagrams take a couple of seconds to generate but well worth the wait
(They are limited though, can only display links between classes for a single unit (this can be somewhat misleading I think and is unsuited for my one object/class per file development wishes ). One idea is to copy & paste all code into a single unit and then display that, this takes some editing work though, another option may be to use includes and split files into interface and implementation like c/c++ and then include them all into a big file).

Monday 20 august 2018 Tired today, messed around with GExperts source code, interesting tool, unfortunately it cannot replace space with tabs or vice versa via grep search (to apply to multiple files via results), did file a bug report. Also wrote a test program to shed some light on ASIO (audio stream input output) api control panel latency buffer adjustment bug, when buffer is resized while buffers are being filed creative lab's asio driver/dll seems to crash, not sure though, could also be a Delphi code issue. Reported this to a maintainer of a fork of asio I think and he might look into it, though it depends on people's soundcard and driver installed, this problem might be driver specific or perhaps not. Thinking of continueing corewar project by applieing back some code from underlying blockchain and then implementing some hashing changes so it can use some corewar/redcode specific techniques, for this I will first need to replace tabs with spaces or vice versa to make code comparision a bit easier. I also found another nice tool a few days ago maybe yesterday called Code Compare... quite a nice tool, it has a freeware version, highly recommend this tool already it can do file and folder comparisions... only annoying this is it default to file comparisions when it starts up, but maybe I can get rid of that so it shows nothing/no default project Meanwhile underlying blockchain technology might change a bit so I am keeping an eye on that as well May have to dive back into the re-structured fork of it, to discover exactly how it produces "blockchain forks" or subchains... this is kinda interesting to know it might even be required... also still interesting to analyze security of this underlying blockchain further.

(It was a bit a funny experience downloading GExperts source code via SVN, it downloaded all the branches/tags and trunk, which in total is 650 MB, this took quite a long time, finally I deleted the branches/tags which was something like 625 MB, don't need those, not sure if Delphi IDE can used to specific to download trunk only, I guess this is done by specifieing this particular folder, not sure if that will work though, may try that next time. I renamed the trunk folder to: trunk (Revision 2388), so this is the revision used for GExperts for Delphi Toyko 10.2.3 and worked flawlessly, it does default run a debug window in the taskbar though, this was at first annoying a bit, cause it popped up every time I started Delphi... confused the hell out of me, cause I already run the exe out of curiosity so first was like wtf this keeps popping up, but it's a nice feature to debug gexperts itself I guess this downloading took quite a long time... was kinda interesting to see how this tool was created... it's quite large... I kinda intrigued by the test files... not yet sure what that's supposed to be ? automated testing ? or just files to test the gexperts operations/processing on ? I am guessing the latter.)

Something wrong with todays tools though. Processing files individually is kinda not suited anymore for todays era of big software projects. Kinda wish they would integrate windows explorer and use checkboxes on the tree to indicate which files to include for processing/compiling/replacing text and which ones not... especially if entire sub folders can be check marked... and also file extensions specified to filter the processing.

There was also an amuzing little bug in code compare which kinda confused the hell out of me, the *.dcu filter wasn't working. Today I noticed there was a little space in front of the * which made this tool fail to recgonize this filter, now it can nicely filter away those annoying dcu files (delphi compiled units)

(Bit bored with Skybuck's Corewar Simulator application for now... <- I think it's good enough for my purposes for now if the need arises to test large warriors) next few days I will probably re-focus on learning underlying blockchain better to be able to successfully modify it to do what I want ! =D

Sunday 19 august 2018 I worked some more on Skybuck's Corewars Simulator, it's now up to version 0.40 and I am starting to like this version ! =D Simulator Settings can now be set and will have an effect.
Some more work will need to be done on visualizing process queue, and visualizing private space, and I also want a private space view, and then maybe also handling visualizing bigger cores. Once these major facilities have been built in I may decide to release this version onto the world ! Then later additional features may be: 1. saving simulator settings 2. setting breakpoints in core view/simulator and finally in the futher future 3. selecting instruction set between 88, 94, and my spec2009. Though I don't really set any motivation right now for feature 3, that is more out of curiosity and completeness sake, so that's on the "backburner" for now =D
Another feature which comes to mind is 4. saving form positions and 5. a reset to default form positions. Oh yeah and also 6. A working/updated execution status of different internals of the simulator would also be nice, like a "debug view of the cpu" (only then will it make sense to 7. bring manual execution controls online/in working state to see how instructions are executed part by part (called actions for now).)

Google corewars and redcode and maybe koth, you should be able to find a lot of information !

Thursday 16 august 2018 Last two days I did some investigation into why the warriors are not evolving. First I thought it might be because there is no evolver process running or maybe it needs more processes running at the same time, but now I am starting to believe that the idea that software could evolve itself out of the blue might be wrong, or the chance of this occuring is really really low. Thus for this project I will probably have to fall back on more "god-like" code, or "radiation" code where instructions are slightly modified by an external process. I could still keep current design and simply apply radiation to both evolver and evolvee That could be fun to see if maybe eventually some self-evolving occurs or not... this is a bit of a bummer though.

17 august 2018 Hmmm I just had an idea how to improve the self-evolving, so I am not yet giving up on this idea ! Secret idea for now, but the hint will be: "stop playing for god at the initial state"
Implement this idea, made the necessary changes... little bit more interesting now, still not self-evolving though =D May have to re-focus on blockchain itself instead of evolving, but for now having too much fun and interest in evolving, project won't be as much fun for me at least if it doesn't have a good "default-evolver" so for now will probably continue into this pursuit of a good default evolver for a while

18 august 2018 worked some more on more corewars simulator, didn't really get very far yet at implementing the rest for the GUI, restructured GUI to allow floating windows, not sure yet if I liked it but with certain positions for the forms it might still be nice, also perhaps some docking and undocking support, and/or use of frames the restructured/form code can be continued to be used. I think it will be usefull to get a slightly better corewar simulator working that has all features implemented, like coresize settings and also more visualization of processes. Shouldn't be a lot of work to do... but does require some effort... I may also try and spent some time on a better gui design, though once I start using it I do notice, it's kind of a new gui design from certain point of view.

So the site of corewar isn't ready yet.
Where should we seek for more information about corewar, if he site isn't ready to be access yet?

Wednesday 15 august 2018 Decided to implement this evolving of evolvers in BattlefieldEvolver first since it already has all the code/plumbing in place. version 0.48 and version 0.49 leave the processess existing for the evolvers. Tested warrior sizes of 100 and 20.... so far it does not seem to be evolving the way I would like to. Also it's been since 2009 since I last tried evolving some warriors... kinda forgot how much time it takes =D
This could be a good thing or a bad thing depending on how you look at it. This project might be in a bit of trouble =D

One possible solution is to focus on coin system/protocol first and let external parties try and develop evolvers or plug in their warriors. Though I would kinda like a warrior evolution system in place. One idea which comes to mind is a distributed warrior evolution system where multiple parties work together and the one that finds a better warrior might be rewarded... bit like a lotto... not sure if this is a good idea... looking at a battlefield like that might be some fun though. First I have to figure out why it's not evolving though...

Sunday 12 august 2018 played Dead Cells ! Whicked game ! =D LOL.

Monday 13 august 2018 thought some more how to implement my much desired evolution tree evolver instead of battlefield evolver . Probably going to have to base it on battlefield evolver and replace battlefield with "treefield" or something like that, to safe lots of programming effort, though some of the new programming effort can be re-used to implement some more advanced features.

Tuesday 14 august 2018 significant progress has been made with implementing trees. I decided to keep it simple (already thought of that on monday) and implement the most easy version possible, by copy & pasting code  from other files, to put together source code exactly like I want it or at least something that is easy to use, complete and just well tested and easy programmed sort of using this new design implementing new features will be very easy and very fast, also it will even safe some processing since this new structure is more efficient/smaller and does exactly what I kinda wanted ! Today is a remarkable day. In 2009 I designed the 2009 specification and today for the first time I have seen random "generated" warriors using it. I never did that before, so this is pretty cool ! It may turn out that the new warriors might be using this specification a bit too much or not at all, and it can't use too much, thus using it much might be a good thing... at least for evolvers =D. I am now entering totally uncharted territory/waters ! =D I have no idea if these evolvers are going to work, but I am confident and full of hope ! =D (I already know older/statistics code worked, this new idea is like the old idea on steroids, sort of ! as long as the evolvers can make some sense of it... it's a bit different though, it does not analyze warriors yet, but perhaps I may build in that functionality later on if it turns out evolvers are not good at evolving warriors without further input/data from existing warrior code bases.)
(Loading/Saving and generating evolvers was easy to implement. Now the more interesting part is to be done. Making the evolvers evolve themselfes and generating warriors, by executing it in a redcode executor, this is again new stuff, never tried before... this is the part where it's about to get interesting ! =D... then they still have to be battled these "clones"/"generated warriors"... since the few first batches/species will probably suck, so there is no fast way of telling if this is going to work, for this a simulation/evolution session will need to be run, so that is the next step... implementing this and then doing some small evolution runs ! This will allow to evaluate if the general idea is working somewhat or not at all ! And this should give some sense of what fast warriors improve or not at all, and if perhaps something needs to be done to increase good evolving speed, for now all bets are off and just gonna let it be in it's first initial concept ! )

What is kinda funny though is I can already run these warriors in my own corewar simulator which is available on the internet, so for the fun of it I am going to try that, another premiere/first ! =D yeaaaahh.

Running the evolvers works. Copieing warriors from them works, these are saved/loaded too for now (just in case... just to be consistent/persistent).

Now all that is needed is "simulator" to be modified so it uses these slighty new/changed TRedcodePrograms and then battle the warriors... and finally swap the best one up with worst one, and generate a new one for the very worst one for battling probably requires a "gathering" of warriors into a list or so... to be able to battle them for a certain "group". These implementations will be done after some good night sleep !

For me, this is a unique project, this has some kind of codes that act as a warrior that will fight for honor ( in this case "point").
This sounds like playing a video game that you have a cheat code to play the main character all by itself to gain some points from every winning war.

Thursday 9 august 2018 went shopping/seeing around for new glasses, found a nice one, first wanna show it to somebody else lol.
Friday 10 august 2018 went to meeting, did watch some blackhat presentation slides about hidden instructions in via c3 processor, interesting, method of detection also interesting.

Saturday 11 august 2018 just heavily modified/seperated corewars executor so that it can now run redcode programs individually, very nice... feels like alien technology ! LOL X-Com music playing ! =D This gonna be awesome I hope/I can feel it ! =D YEAH ! =D (This will be used to evolve evolvers ! =D a new experimental idea that has nice been tried before as far as I know ! =D)

Wednesday 8 august 2018. Completed the data structure for TWarriorTree based on TEvolutionTree. It's now ready to implement all other functionalities. Today was nice cool day, 26 degree celcius mostly.
I will have to do some more thinking first how to properly use these new data structures. Found another way to create the same data structure with just a fraction of the lines of code, will have to evaluatate which one I find more pleasent to work with... hmmm... and there is possibly a third, and even a fourth way of writing the same code. Can't really say that all these new languages features make my life more easy on the contrary, now I have to choose what kind of implementation to use, ahhh, all have their adventages and disadventages, but this is the fun of programming ! =D

Anyway wanna add a little funny note: today, this night 2:22 am or so 9 august 2018 street lights went out, and traffic lights, only for a few minutes, maybe some kind of bug, or automated reset, should try and see if this happens next year as well ! LOL. It's a very rare event that's for sure. Only one street seemed to go offline, kinda weird. (This could also have been a sign of hacking).

Tuesday 7 august 2018. Tried to solve some crypto riddle, not solved yet. Filtered my pyramid scheme idea text for valuables ideas, basically took over it's ideas tought about it some more and worked it out, I am not pretty sure I will want this design eventually, might implement it directly, or might first try a simpler design, though a simpler one might not work too well, but will be less computationally intensive. I am kinda intrigued by by currently more complex design and thus will probably try and implement that tomorrow with hopefully a fresh and energetic start of the day ! =D Though maybe I even try it now, not yet sure... usually I want to sleep on new ideas, though this is not exactly a new idea, just to be sure I don't wake up in the morning with an even better idea/design and then wasted effort/energy the night/day before it! Also one should have plenty of energy when implementing new designs, otherwise when low on energy, corners may be cut, and that may be regretted later on with weaker/messy "cut designs/implementations"

Also wanna do some WoWs right now and yeah one more thing now temperature records were broken today, at least not indoors, still 32 degree celcius or so, it was a bit cloudy so that might have prevented extreme heat from developing cause some percentage of the sunlight probably reflected back into space. There is another kind of record though, right now 0:03 at night it's still 30 degree celcius, never seen such a high temperature at night, at least not that I can recall, so I will enjoy this blog, assuming it still exists then, in the future ! =D

Renamed this thread from Corewar Coin to CoreWarCoin... I think that will be better for the future.

Monday 6 august 2018 TEvolutionTree data structure version 0.03 created, if everything goes well this data structured will be used to evolve warriors in a "origin of spieces" / darwin kinda way ! =D It's design is basic for now and may have to be adepted in future, might make a virtual tree of it, not yet sure how to proceed with it, but it's creation and destruction is implemented and working correctly for now ! =D

And now time for a weather report lol. The heatwave in Europe/The Netherlands continues... today is 32 degree celcius in doors, pretty much a record, cannot remember or very vaguely when I last saw such a high temperature, windows/doors open nice cool little breeze blowing =D Tomorrow will probably be the hottest day, 36 degree is expected, very curious if this record will be achieved ! Using this nice oppertunity to
de-frost my refridgerator, god knows it was necessary ! LOL. Then in with the pizza and fries/chicken lol which were ordered today LOL. =D
It's fascinating how the ice almost completely evaporated, very little water was spilled Humidity is 24 to 25% right now.
I just had an idea, I put a ventilator on the fridge, to blow away the hard to reach spots of ice !  funny ! =D the cheese inside of it might not like it, but that's ok =D
Yeah it worked, some hard ice out of there, strangely enough I could swear I smelled some of my own aftershave/parfum in that ice ! LOL. Strong parfume LOL, Identified ! =D