Bitcoin Forum
November 10, 2024, 08:34:48 AM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 [3]  All
  Print  
Author Topic: [ANN][CwC] Corewar Coin (Cancelled ! =D)  (Read 864 times)
Skybuck (OP)
Full Member
***
Offline Offline

Activity: 386
Merit: 111


View Profile
August 21, 2018, 02:15:47 AM
Last edit: August 21, 2018, 02:27:32 AM by Skybuck
 #41

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 Wink Meanwhile underlying blockchain technology might change a bit so I am keeping an eye on that as well Wink 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 Wink 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) Wink Smiley

(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 ! Wink =D
Skybuck (OP)
Full Member
***
Offline Offline

Activity: 386
Merit: 111


View Profile
August 21, 2018, 09:52:00 PM
 #42

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 Wink
(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 Wink). 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).

Skybuck (OP)
Full Member
***
Offline Offline

Activity: 386
Merit: 111


View Profile
August 24, 2018, 01:55:34 PM
 #43

Wednesday 23 august 2018 and Thursday 24 august 2018, experimented somewhat with refactoring underlying blockchain technology and tests in general.
Skybuck (OP)
Full Member
***
Offline Offline

Activity: 386
Merit: 111


View Profile
August 26, 2018, 04:15:24 PM
Last edit: August 26, 2018, 06:44:08 PM by Skybuck
 #44

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 Wink

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 ! Wink

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 Wink
Skybuck (OP)
Full Member
***
Offline Offline

Activity: 386
Merit: 111


View Profile
August 28, 2018, 02:49:27 AM
Last edit: August 28, 2018, 03:32:41 AM by Skybuck
 #45

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 Wink.

Thus everything else can stay the same... cheesy, simply perhaps stupid, but maybe it will be fun ! Wink
Skybuck (OP)
Full Member
***
Offline Offline

Activity: 386
Merit: 111


View Profile
August 31, 2018, 02:11:37 AM
 #46

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 Wink Smiley

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.
Skybuck (OP)
Full Member
***
Offline Offline

Activity: 386
Merit: 111


View Profile
September 01, 2018, 03:28:53 AM
 #47

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" Wink Smiley 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 Wink (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.).
jacasta19
Newbie
*
Offline Offline

Activity: 75
Merit: 0


View Profile
September 01, 2018, 06:14:23 AM
 #48

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?
Skybuck (OP)
Full Member
***
Offline Offline

Activity: 386
Merit: 111


View Profile
September 04, 2018, 08:01:12 PM
 #49

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 ! Wink Smiley

(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 ! Wink Smiley)

Bye for now.
Skybuck (OP)
Full Member
***
Offline Offline

Activity: 386
Merit: 111


View Profile
January 09, 2023, 10:54:48 PM
 #50

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...
Pages: « 1 2 [3]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!