[ANN][SIM] Simcoin - A Simple Coin

[NxtChg]

Progress report

This week I continued switching tasks to the new scheme of commands and events, which I like very much – it organizes things nicely and gives you great flexibility.

For example, to work with the ini file before there were two functions: ini.get() and ini.set().

Now those functions are re-routed through commands. This instantly makes them available to the host application if it decides to store some of its settings in the ini file.

But that's not all - the host can easily intercept those commands and provide its own storage for all configuration variables!

The same way it can either send commands to write to the log file or intercept them to redirect log messages somewhere else.

It also makes it easier to debug – I wrote a special task that just listens to all passing commands and writes selected types into a file, so you can then examine the history of what was going on.

--

Also scanned my paper notes

[1714625126]

1714625126

[1714625126]

1714625126

[marek3ball-orig]

Holy shit ... BUY ...

[Tobo]

Today is almost exactly 9 months since Simcoin started (jeez, time really flies!).

To celebrate, all Simcoin stakeholders will get a small present today – everybody’s stake will be increased by 1%!

Happy Holidays!

+1. Thanks!

[mladen00]

thank you dev

wish you all the best in 2015.

[NxtChg]

A good article:

http://ventrellathing.wordpress.com/2013/06/18/the-case-for-slow-programming/

[NxtChg]

Progress report

Not a bad week, considering all the holiday distractions.

Tasks can now run at different levels to allow ordered processing of commands. There are also two passes for each command. This way I can emulate OOP, where a higher level task can extend a lower level task functionality by modifying incoming and outgoing commands. Or create "filters" that intercept certain commands. Not sure whether to expose this to hosts, but at least that's how it will work inside the core.

Finalized quitting synchronization between the host and the core. This is important because they run in different threads.

Continued adding more commands and documenting them in wiki.

Packet addressing changed to be transport-independent. This is the most flexible solution; now the core can handle packets regardless of how they arrived, via UDP or some other method.

Triage task started, its job will be to prioritize incoming packets and limit packet rates to prevent attacks and abuses. It will also be responsible for packet encryption now, to make it easier to implement alternative transport protocols, if needed.

Almost whole day spent restoring simcoin.info, because the %$@#%& qhoster just lost my VPS and refused to do anything about it "because New Year"! Still waiting for them to restore it! Stay away from that "company", seriously. It was foolish of me to keep a server with them, even for things that are not so important.

Also modified my PHP WebSockets server to use streams instead of sockets, so it could support secure connections (wss:// instead of ws://). Surprisingly, it worked

[twistelaar]

Hello Dev!

I was thinking.. You are already busy with the website/design/promovideo/logo? Maybe hire somebody? I can recommend Bitcrea, he accepts BTC or SIM and he can do all the above. Check out his website:

http://bitcrea.com/

[cryptodevil]

Is any of this of relevance to Simcoin's future in terms of Quantum computing being a potential future threat to crypto?

http://en.wikipedia.org/wiki/Supersingular_Isogeny_Key_Exchange

The Supersingular Isogeny Diffie–Hellman Key Exchange (SIDH) is a post-quantum public key cryptographic algorithm used to establish a secret key between two parties over an otherwise insecure communications channel. It was designed to resist cryptanalytic attack by an adversary in possession of a quantum computer. Because the SIDH has key sizes and computations similar to the widely supported Diffie–Hellman key exchange it is a natural candidate to replace Diffie-Hellman in the face of a growing quantum computer threat.

[NxtChg]

Is any of this of relevance to Simcoin's future in terms of Quantum computing being a potential future threat to crypto?

http://en.wikipedia.org/wiki/Supersingular_Isogeny_Key_Exchange

I have enough things to worry about without quantum computers

[NxtChg]

Progress report

This week I was converting the client to use simcoin.dll core.

It was more time-consuming because the client was much more messy (the main reason that motivated me to move all the simcoin core functionality into a separate library).

Also because the client acts as a middle layer between the core and the Java Script code: since JS can't use commands/events directly, they needed to be wrapped in a set of API functions.

The conversion is not yet finished, there's still some more work left.

[wizzardTim]

Nice! Keep up the good work!

[NxtChg]

CryptoPlay announcement: https://bitcointalk.org/index.php?topic=927003

[Nxtblg]

CryptoPlay announcement: https://bitcointalk.org/index.php?topic=927003

Congrats.

[mcjavar]

Could we have an updated roadmap for the development/release of Simcoin? Merci!

[Tobo]

CryptoPlay announcement: https://bitcointalk.org/index.php?topic=927003

Nice dividends! Thanks!

[Mu_XuE]

  ;DGood!

CryptoPlay announcement: https://bitcointalk.org/index.php?topic=927003

Congrats.

[jokumat]

I would like to know - the account password (in the exchange) is only 8 characters. Very short. This can be bruteforced easily, no? Is it safe? Is the account blocked after unsuccessful attempts or something like this?

[NxtChg]

One way to reassure me personally...

And why would I bother?

[NxtChg]

I would like to know - the account password (in the exchange) is only 8 characters. Very short. This can be bruteforced easily, no? Is it safe? Is the account blocked after unsuccessful attempts or something like this?

You think it's feasible to bruteforce a 8-character alphanumeric mixed case + digits password over the network?

Do the math.

[NxtChg]

Progress report

This week I took care of communication ID collisions. Since the ID is 4 bytes long there could be collisions as the number of users grow. For 4,000 users the chance is one in a million, but for 4 million, it's one in a thousand.

Previously I left this to be dealt with in the future versions, but since commands are now a documented interface, I had to think how to handle collisions and implement the solution.

By the way, I could have probably saved myself about a month of work if I didn't bother to encrypt packets, like all the other coins don't.

It's one of those tasks that seem relatively simple to a regular person ("You just need to call something like encrypt(packet) and that's it, right? How hard could that be?"), but prove to be much more complicated in reality. Because before you can call encrypt(), you need to get a key and this unfolds a whole chain of events and problems. I might tell you more about it one day

But anyway, I found more or less simple ways to deal with all the complexities, so now collisions are taken care of.

--

Spent some time adding automatic indentation to wiki sections. Some articles became quite large and difficult to read. So had to figure a way to do it.

--

I will post the new roadmap once the refactoring is complete, but in general I am at the stage where most of the things kinda work, but there's still a gazillion of small tasks to be done.
 
This is Simcoin right now:



You can see the whole building, but still need to lay thousands of small bricks to fill the walls.

And here's how software development works:



Most indie projects fail in the Q point, when the going gets tough. You see it all the time – a few young hotheads gather together and decide to do a super cool game and in a couple of weeks they post cool screenshots, which look almost like a complete game. And then it never goes anywhere beyond that point and project members get frustrated and quit.

Why? Precisely because of that graph. You work and work and nothing seems to happen and it feels like you're stuck and will never finish it.

Here are just some recently closed items from my to-do list:

+ Tasks::add(): protection against null pointers.
+ BUG FIXED: Incorrect check "!find()" for array when it returns 'int' instead of 'bool'.
+ BUG FIXED: Can't init TaskDesc before inserting! Otherwise it references itself by ID and it's not in array yet.
+ BUG FIXED: set 'done' to 'true' in Tasks constructor, otherwise init() will wait N seconds for the non-existent thread to finish
+ Set reason in sim.quit() and don't reset it for 'quit' command, so we could return errors this way.
+ Move socket and NetStats from Packet into T_Net.
+ Bruteforce ID collisions in Tasks::add(), otherwise every 16 M tasks there might be a problem...
+ Suicide tasks a bit differently. 'dead' array.
+ INI: Remove the variable if an empty string passed.
+ KVS walk functions. dump(). Bug fixes. Big endian keys, key size added for that.
+ "OK" reason to mark processed command.
+ Sending sim.quit() in on_exit handler.
+ 'level' parameter for sim.start_task.
+ Default level for tasks into task factory.
+ CmdLog: add indent.
+ BUG FIXED: outgoing() pass wasn't executed for orphaned commands, this could lead to wrong indent in CmdLog because incoming() wasn't paired.
+ Tasks::print()
+ BUG FIXED: 'quit' message must be sent only in one pass.
+ SimApi::out_raw_packet.
+ 'bool4' type for commands to make misalignment less probable.
+ 'is_node' into 'comm_key' command.
+ BUG FIXED: outgoing task no was 1 more than it should, because after the loop it's invalid. And also if you processed a command you shouldn't receive outgoing() call anyway.
+ BUG FIXED: outgoing must cycle till "i >= 0" instead of "i > 0". D'oh!
+ BUG FIXED: Tasks::add("") didn't set the level and it also didn't set it properly. 2-in-1 bug.
+ Client's data path from DLL path.
+ Rename 'hash' into 'hmac4' and use 4 bytes instead of 3. Update wiki.
+ Triage::get_peer() that will deal with comm_key event/adding internally.
+ KPS::next().
+ Change Triage to use next() to cycle through all keys and decode proper one.
+ Damn, 'account' and 'is_node' must be returned for each key!
+ operator == to Hash32. Store hmac in vault as Hash32 instead of byte[32]. Need to convert everywhere.
+ Hash32: added a bunch of functions to support "Hash32().add(prefix).add(msg,size).calc();" style of programming.
+ Hash32: zero buffer after stretch() to clear passwords.
+ Tasks::add(): don't add tasks if quitting.

And it goes on and on and on…
The to-do text file is already 329 Kb in size!

There's no other way than to just grit your teeth and keep going...