1. Ryler Sturden

    Ryler Sturden Member Staff Member MC Developer

    In the last weeks I have resumed development on MicroCash, a continuation of the refactor/rewrite that myself and Michael Lanthros (https://microcashblog.wordpress.com/) worked on last year, which was based on code I wrote in 2012. I currently plan on releasing the first alpha around February 7 2016. Binaries only, hopefully for all the major platforms. The release schedule for the MicroCash node will for the time being follow my motivations on working on it as I am the only C++ coder working on it. My motivation, as anyone who knows most coders, is like the tide in that it comes and goes. Hopefully though we can get more C++ coders to work on it so it is not so reliant on me. I will be donating around $5000-$10000 to the project so the team can do what is needed, such as buy forum software like this, SSL certs, run servers, and get others involved. I hope others can help out too.

    So far MicroCash is still in an early state, however the framework and base code pieces for the entire application are nearly present. So it is just a matter of tying everything together and working together on what exactly MicroCash needs to be to be useful to the world. Once we are through the alphas and betas and finally released the source code will be released under a MIT or MIT like license so it will be free to use however anyone wants, like Bitcoin. So yes that means anyone can fork it, and create "altcoins" from it if they want, etc, etc. Not that creating altcoins is necessarily in MicroCash due to the inbuilt possibility for sidechains.

    My main effort in my recent work has been to fix up and refactor some of Michael's work and give a wallet to the node. The wallet will actually be usable from a web browser as I have created an optional, basic web server inside MicroCash itself (I even borrowed a little code from my custom exchange code :) ). You just point your web browser at your local node (localhost ) and it will auto-create an admin account for you and then allow you to use your node as a wallet for yourself and other users. I want the experience of using MicroCash to be as simple as running a binary and using your web browser, something everyone is familiar with. Editing config files and such is not a friendly way of operating in 2016.

    Exported from the same http interface is the API which will take a structure like . The API will be useful to anyone developing services for MicroCash and will be easy to use anyone familiar with the Bitcoin RPC API or general web development. The wallet on the node is basically just a UI to hook into that same API , the idea around this is to completely minimize the work needed to get MicroCash off the ground into a usable state and to make it easier to extend going forward. By making the wallet HTML code it also opens up who can help with developing the wallet and making it better. You'll be able to extend the wallet code yourself in the first alpha released and get a taste for the API.

    Currrently MicroCash has only one external header-only library called ASIO, but it is included in the source structure, which means the source package for MicroCash has zero external dependencies. Once C++17 is out ASIO can be removed as ASIO will be incorporated into C++17. Currently MicroCash needs a C++11 compiler, going forward the use of latest C++ technology to improve the readability and performance of the code base is a must. I do not want MicroCash to turn into a rube goldberg machine of complexity where only a handful of people on the Earth can understand what it is doing.

    An important goal with MicroCash is to have the entire source code free, and for the entire source code to do exactly everything needed for MicroCash with no external influence. This is an important goal which must continually be met throughout the life of MicroCash. Reliance on external black box libraries for cryptography, databases, networking, etc whilst making a project sometimes easier to make also open it up to attack vectors and make it harder to debug.

    Also I heartily ask that anyone who is the slight bit interested in a truly free and secure cryptobank for the world to offer your suggestions, comments, critiques, etc. What MicroCash is at the moment is not set in stone and there are many things which need to be ironed out in regards to things like economics, core features which need to be there, etc. Hopefully some of the other guys will be starting these discussions soon so others can join in and offer their views. Thanks for taking the time to read this.
    Last edited: Feb 2, 2016
    fellow, MrSonic and SuperTramp like this.
  2. Ryler Sturden

    Ryler Sturden Member Staff Member MC Developer

    Here are two images from the current HTML MicroCash wallet. Yes I know they are ugly, it is that way on purpose so I can just get the functionality in and so that others are enticed to make it pretty! :)

    Attached Files:

    • mc1.png
      File size:
      31.9 KB
    • mc2.png
      File size:
      33.8 KB
    SuperTramp likes this.
  3. fellow

    fellow Member

    As soon as the alpha is available I will take a look on it and create some mysql database framwork for it on which people can base a blockexplorer or richlist on.
    SuperTramp likes this.
  4. Ryler Sturden

    Ryler Sturden Member Staff Member MC Developer

    Hi fellow that sounds great. Making a "block explorer", which would just be called a "transaction explorer" in MicroCash as there are no blocks, should be really easy because there will be one built into the wallet already using a simple JSON api. You could literally just cache those results, copy the wallet code and have the same thing up on the net in no time at all. I think it is important for an open network to allow people to easily see everything that is going on, and all the accounts on the network. Also helps with debugging too. :)
  5. Ryler Sturden

    Ryler Sturden Member Staff Member MC Developer

    I'm trying to spend nearly no time in the design of this wallet so the colors and overall feel of it are pretty bad, but the framework of the wallet is coming together nicely. The hope is of course that you guys will take the HTML and make it better :) Either way, the end product will be completely configurable by the user if they so desire, could have completely different themes and such easily.

    I just have to do a couple more things to get the wallet creating MicroCash accounts and the alpha is nearly ready.

    First time you connect to your node.
    Login screen

    Logged in screen
  6. notyep

    notyep New Member

    Looking sweet as usual! Still miss the look and feel of the original MC client you did but I'm sure this one is leaps and bounds better!
  7. Ryler Sturden

    Ryler Sturden Member Staff Member MC Developer

    It will be a lot better in the end. It looks like shit now I get that but one of my problems is UI perfectionism. So I know if I start to just play around with the UI I'll waste time rather than be productive. If you know how to edit HTML files and javascript you can even improve it yourself. Just start with editing the style.css file to get color changes going.
  8. Ryler Sturden

    Ryler Sturden Member Staff Member MC Developer

    Some updates on alpha 2.

    *mishak said he will work on the wallet HTML/javascript which is good news. Hopefully it can start looking much better soon. If anyone else wants to submit some changes please feel free to.
    *I rewrote nearly all platform specific code so that it relies on nearly no OS specific features. Currently only the windows service code and a bit of UDP code is platform specific.
    *Fixed many bugs and warnings to get it to compile on GCC, it now does so with no warnings. MSVC was more loose with its acceptance of things
    *Increased amount of logging and error console output as initially running the linux build it was not working correctly due to a file permissions issue. Adding more logging helped pinpoint the problem and for now I will keep it in to help with the alphas.
    *Now using std::experimental::filesystem instead of platform based code we wrote. It is experimental, which means you need more modern compilers but MSVC 2013+ and GCC4.9.2+ both support it and it makes our lives easier. It will be going into C++17 however so it is safe to use.
    *Will eventually look into a OS X build, it should be very simple now that linux is compiling.
    *Linux build looks, feels and acts exactly the the windows build and going forward should be an easy 20 second job to compile it and the Mac versions.
    *necom is Looking into getting some digital signing for the windows executables.
    *necom put up a private git hosted on microccash.org so we can start sharing the source code with new developers if/when they join the project
  9. Ryler Sturden

    Ryler Sturden Member Staff Member MC Developer

    Some more updates on alpha 2.

    I have added the ability for each MicroCash binary to have multiple peer to peer nodes, currently set to a hard limit of 3. So you will find that in settings.txt


    The first server is enabled by default, the second two will be disabled by default, but can be started and configured from the web interface. You'll be able specify multiple ports, directories, etc in the settings.txt or web interface and have multiple servers running in the one binary. This will mainly be to help testing, debugging, and benchmarking the system but it could be useful for certain firewalling/proxy situations also.

    For benchmarking you could load millions of transactions into one of the nodes and then connect a blank node and time it so it tests the entirety of the pipeline, network, etc. All without requiring the user to do any weird setups with multiple installations.

    It could also be used in the future for sidechain projects, or even completely different projects that use some similar aspects to MicroCash. I'm sure there are many possibilities I can't think of.
  10. RLH

    RLH New Member

    Question: How will the transaction chain be organized? Long ago, the idea was that all transactions would have a hard-sort. This would allow for quick verification because once a TX was accepted on the ledger, it was their for good. The only required verification would be that the TX was well formed an that the assoc. account had the funds.

    So, how have you changed the transaction handling?
  11. RLH

    RLH New Member

  12. Ryler Sturden

    Ryler Sturden Member Staff Member MC Developer

    It is pretty much as you describe it still on a basic level. 2 sigs per TX, state checks for funds, and a couple simple rules that allow some flexibility for sidechains. I'm building in a way to name addresses by default so that payments can be linked to text, this is a small rule and easy check so it won't slow down the nodes. But a different naming system, for DNS or something like this can easily be added as a separate sidechain project, that is controlled/governed by whomever and whatever (First comes, Proof of work, proof of stake or whatever digital system is deemed fit).

    Each MC account has a data section that the owner can insert data into, this again can be used for a variety of things and is left up to the community to take advantage of. So you could have a named account, lets say, "RLH", and in the data section you could put a description, or a signed message, or something that proves you are who you say you are giving the sender a happy secure feeling. Just one use, there are thousands others as Bitcoin/litecoin/doge/Nxt/ethereum has done and we have talked about before. The main difference I guess is MC is 100% secure, trustless, scaleable and instant whilst those other systems to this point are not.
  13. Ryler Sturden

    Ryler Sturden Member Staff Member MC Developer

    I spent a lot of time today working on a custom memory allocator for MicroCash, which is basically a way to track when memory is requested and destroyed by MicroCash. Usually you just call new/delete/malloc/free/etc and the standard library and OS take care of it. However there are issues with just relying upon the OS to do its job.

    I also added the ability to do memory checking in debug builds so that we can be sure there are no memory overwrites, corruption, etc. On top of this eventually I will make sure that the node will gracefully shut down from a low memory situation instead of just destroying itself like apps do when memory runs out. It is very important that a node can be run in a stable condition for many months without requiring downtime and this memory tracking will help with this process.
  14. Ryler Sturden

    Ryler Sturden Member Staff Member MC Developer

    Here is an example of the memory corruption checks which are now possible.

    Memory corruption caused by x:\projects\mc\main.cpp [42] - 100 bytes

    And the cause?

    int *b1 = new int[25];

    Allocating a 25 integer array, and setting the 26th item (C++ is 0 index based, so 0-24 is valid) gives us the error now.
  15. fellow

    fellow Member

    This sounds really reasonable for situations in which the size gets set by a variable.

    What I also can also think about to prevent "loosing memory over time" would be some internal memory consumption estimator/calculator.
    In other words you sum up what you allocate and release to cross verify with what the OS tells for the thread(s).

    A simple external version would not require to include any additional OS dependant libraries since a external tool could monitor the pid and verify it with the console output (not as good as a integrated approach but a increase over time would be recognized).
    Another way instead of console output would be to write periodically into a file which can get parsed by shellscript or as api query.
  16. Ryler Sturden

    Ryler Sturden Member Staff Member MC Developer

    Yes the memory allocation amount is exported in the API and shown in the UI interface and will be available to see in ALPHA2. It is only dynamic allocation and does not take into account internal OS allocations for things like network sockets, files, etc. Right now it is using ~8KB of dynamic memory which seems incredibly low considering it is running a node and a web server.

    Everything that is useful will be exported in the API so that you just call and have the data, any time you want, anywhere in the world. Being able to remote many servers will be possible with the right wallet/ui changes too.

    I may make the release build have some form of memory checking too, less than the debug version. Or at least make it optional because it is highly useful to do such a thing, and since it is in MicroCash itself it means it will be available on every platform we target. You can use tools on each platform which help with this but the tools do not give you the flexibility we now have.
  17. Ryler Sturden

    Ryler Sturden Member Staff Member MC Developer

    Here is some output. Currently there is a fair amount of "unfreed" memory because much will only be removed when the global objects are destroyed. I'll try to address it if possible so they are also removed, or maybe not count the unknown memory because it was allocated elsewhere.

    - 480 bytes ADDRESS: 00000087A328DC80
    - 480 bytes ADDRESS: 00000087A328DA60
    - 304 bytes ADDRESS: 00000087A328D8F0
    - 192 bytes ADDRESS: 00000087A328B290
    - 192 bytes ADDRESS: 00000087A328B790
    - 488 bytes ADDRESS: 00000087A328D6C0
    - 192 bytes ADDRESS: 00000087A328A690
    - 232 bytes ADDRESS: 00000087A328D590
    - 192 bytes ADDRESS: 00000087A328A190
    - 200 bytes ADDRESS: 00000087A3283230
    - 192 bytes ADDRESS: 00000087A328A590
    - 200 bytes ADDRESS: 00000087A3283120
    socket.cpp(91) MC::CSocket::CSocket - 184 bytes ADDRESS: 00000087A328B690
    - 192 bytes ADDRESS: 00000087A328A790
    - 240 bytes ADDRESS: 00000087A328D460
    - 480 bytes ADDRESS: 00000087A328D240
    - 480 bytes ADDRESS: 00000087A328D020
    - 304 bytes ADDRESS: 00000087A328CEB0
    - 192 bytes ADDRESS: 00000087A328BA90
    - 192 bytes ADDRESS: 00000087A328B490
    - 488 bytes ADDRESS: 00000087A328CC80
    - 192 bytes ADDRESS: 00000087A328BF90
    - 232 bytes ADDRESS: 00000087A328CB50
    - 192 bytes ADDRESS: 00000087A3288B90
    - 200 bytes ADDRESS: 00000087A3282CE0
    - 192 bytes ADDRESS: 00000087A328A090
    - 200 bytes ADDRESS: 00000087A3282F00
    socket.cpp(91) MC::CSocket::CSocket - 184 bytes ADDRESS: 00000087A327D6A0
    - 192 bytes ADDRESS: 00000087A327D5A0
    - 240 bytes ADDRESS: 00000087A3281320
    - 480 bytes ADDRESS: 00000087A3288920
    - 480 bytes ADDRESS: 00000087A3288700
    - 304 bytes ADDRESS: 00000087A3288590
    - 192 bytes ADDRESS: 00000087A327D3A0
    - 192 bytes ADDRESS: 00000087A327D2A0
    - 488 bytes ADDRESS: 00000087A3288360
    - 192 bytes ADDRESS: 00000087A327D1A0
    - 232 bytes ADDRESS: 00000087A32811F0
    - 192 bytes ADDRESS: 00000087A327CAA0
    - 200 bytes ADDRESS: 00000087A3283010
    - 192 bytes ADDRESS: 00000087A327D0A0
    - 200 bytes ADDRESS: 00000087A3283560
    socket.cpp(91) MC::CSocket::CSocket - 184 bytes ADDRESS: 00000087A327D4A0
    - 192 bytes ADDRESS: 00000087A327BDA0
    - 240 bytes ADDRESS: 00000087A32810C0
    microcash.cpp(231) MC::InitP2PServers - 1984 bytes ADDRESS: 00000087A3287B60
    - 208 bytes ADDRESS: 00000087A3286C00
    - 192 bytes ADDRESS: 00000087A327CBA0
    - 192 bytes ADDRESS: 00000087A327CFA0
    - 192 bytes ADDRESS: 00000087A327D7A0
    - 192 bytes ADDRESS: 00000087A327BEA0
    - 192 bytes ADDRESS: 00000087A327C6A0
    - 192 bytes ADDRESS: 00000087A327C4A0
    - 416 bytes ADDRESS: 00000087A3286D90
    - 208 bytes ADDRESS: 00000087A32869B0
    - 208 bytes ADDRESS: 00000087A3286AF0
    - 256 bytes ADDRESS: 00000087A327B2D0
    - 192 bytes ADDRESS: 00000087A327B1D0
    - 224 bytes ADDRESS: 00000087A326D400
    - 192 bytes ADDRESS: 00000087A327B0D0
    - 256 bytes ADDRESS: 00000087A327AF90
    - 192 bytes ADDRESS: 00000087A327AE90
    - 224 bytes ADDRESS: 00000087A326D880
    - 192 bytes ADDRESS: 00000087A327AD90
    - 256 bytes ADDRESS: 00000087A32767D0
    - 192 bytes ADDRESS: 00000087A32766D0
    - 224 bytes ADDRESS: 00000087A326D2E0
    - 192 bytes ADDRESS: 00000087A32765D0
    - 256 bytes ADDRESS: 00000087A3276490
    - 192 bytes ADDRESS: 00000087A3264A00
    - 224 bytes ADDRESS: 00000087A326D0A0
    - 192 bytes ADDRESS: 00000087A3266FD0
    - 192 bytes ADDRESS: 00000087A3273C00
    - 224 bytes ADDRESS: 00000087A326D760
    - 192 bytes ADDRESS: 00000087A3264DA0
    - 192 bytes ADDRESS: 00000087A3269E30
    memory mismatch 20312 in buffers vs 16056 recorded
    Total Unfreed: 20312 bytes
  18. fellow

    fellow Member

    I guess the username/password url is only used for the alpha tests like the plaintext password in the username.mcx file ;-)
    Will the release user auth send hashs of the entered passoword to the server or use regular http auth methods?
    Not that I do not prefer to send only hashed and maybe dynamically seeded passwords to the server but I currently work on a roadmap for a mysql backed transaction explorer and wonder if a simple curl call is sufficient or wether I require to add something more.
  19. Ryler Sturden

    Ryler Sturden Member Staff Member MC Developer

    I hope to have SSL in there at some point which will protect anyone who does it over the internet. If you have any better solutions then you can submit them. Whether basic auth is used, or urls, it is the same level of security in my opinion if it isn't encrypted. Known SSL encryption only protects you from low level hackers, SSL is completely compromised on the govt/black level. This likely isn't true for our own supplied certificates though, but when possible we should look at the best systems to use, not the most used, if that makes sense.
  20. notyep

    notyep New Member

    The folks over at Open Whisper Systems are doing great things for mobile communication encryption. Their Signal app is impressive, perhaps we could leverage what they have for MC (especially if they are interested in branching out into cryptocurrency)...

Share This Page