1. Sujiram

    Sujiram New Member

  2. notyep

    notyep New Member

    Too Funny!!
  3. Ryler Sturden

    Ryler Sturden Member Staff Member MC Developer

    Work on alpha 3 commences. Will be starting on the account system and transaction system, all the components are there already just have to stick them together.

    I also made it so the first time you run the node it will autolaunch a web browser and connect to it for you. Which should be helpful, you can disable it in settings.txt .

    In about a week or so we should have a fully functioning node that sends money around the p2p network and can do other things too. Hopefully the wallet UI can keep up with the pace!
  4. notyep

    notyep New Member

    Excellent !! In times of global economic turmoil such as these, no better time than now for MC to make an impact and fork a new road to financial freedom for all humankind.
  5. fellow

    fellow Member

    Since the wallet is meant to be accessed by "the systems" webbrowser anything despite pure ssl would require to be able to run in javascript.
    I never did it on my own but I can think of utilizing a node.js based endpoint to endpoint asymetric encryption.
    This would completely replace the ssl part and you won't have to deal with installing own certificates to your browser.
    I can also think of alternative ui clients for certain use cases at some point if much traffic has to be encrypted (if node.js slows this down).
  6. Ryler Sturden

    Ryler Sturden Member Staff Member MC Developer

    I had a basic look into it. You cant really do javascript client encryption SECURELY currently for a number of reasons.

    However we can do it "by default" to protect more than pure unencrypted will be, it will be vulnerable to man in the middle attacks and injection attacks from the browser itself. However it is a layer above "pure unencrypted", just not secure in a way you want to bet your life on.

    Having a plugin for a browser seems best. And there may already exist some plugin which can do what we want. I haven't looked, but its a fairly standard problem and once solved is quite generic so I think it may exist already.

    We will need* to do SSL/tls regardless of these extra features. Really the whole concept of security here is often left to the end user. With a VPN you could create a subnet to your node so it can be secure and accessed on the subnet even if it is unencrypted locally.

  7. Ryler Sturden

    Ryler Sturden Member Staff Member MC Developer

    I have been working on exposing more of the EDDSA encryption to the API and command line. This is important for testing encryption keys that will eventually be used in signing transactions and verifying that other transactions are valid. You can now create a EDDSA keypair on the commandline with
    mc64 createkey [filename]

    If you dont provide a filename it will print the key out in hex to you.

    I have also exposed calling the API through the binary itself. This will require an already running node obviously.

    mc64 api user pass commandstring

    This will make some scripting jobs easier to do.
  8. fellow

    fellow Member

    exposing the api calls to itself sounds really great since you do not have to rely on external tools (eg. curl had several releases ago a memory leak which forced me to reboot my machines every couple of days simply cause I called curl in a quite big shellscript loop).
    not sure if it is still like it was but absolutely great that you do not have to use it anymore since there still seems to be issues: https://bugs.centos.org/view.php?id=9391
  9. Ryler Sturden

    Ryler Sturden Member Staff Member MC Developer

    Yes and since bitcoin already allows it and we want migration to be easy we need to support similar. Of course Bitcoin doesn't have an account system or multiple wallets, at least last I checked, so it is a bit more complicated with MicroCash still.
  10. Ryler Sturden

    Ryler Sturden Member Staff Member MC Developer

    I have been working on getting the accounts and transaction system online in MicroCash. Currently I am writing a protocol that will allow testing of the engine in a benchmark called from the commandline.

    A Microcash P2P node will be created, it will have an amount of "real" test accounts created in it with funds created from the root, much like the real launch. So if you want 10000 accounts created, then 10000 transactions will be created by the root and sent out to each account. Each account will then have some funds in it and be able to also then send transactions around the network.

    Once this is all done a few performance tests are done on some specific core features like how long it takes to lookup an account. Looking up an account is a very important facet of MicroCash and it needs to perform really fast. It can only be a single threaded aspect currently, so is not something we can split across cores. But right now I can get 5 million per second lookups on a 3.5ghz i7 which should be plenty fast for a long time.

    Once those benchmarks are done the final test is of course creating another P2P node and having it receive the entire network to that point in the form of transactions. So this is the important test and will use all available cores on your CPU. It will tell us the number of transactions per second you can handle. I don't have a figure yet for my computer however I should soon, I expect numbers over 2000tx/sec which is roughly Visa level, but I will have to wait and see. Once all this is done I can then start optimizing it and hopefully get it a lot higher.

    I realized once I was doing this that we will need to be able to select "Nodes" in the transaction and account section of the wallet because each node may give you different results depending upon where in the network it is at. And for these test nodes I create it would be useful just investigating all the data we create for them I feel. It raises an interesting point in "what is MicroCash" though, because this client it seems will be able to have multiple P2P connections to multiple "microcash" like networks. This could be useful for companies maybe, I'm not sure. People who want a private currency network that they can control unlike the uncontrollable mainline network.

    All this is possible with nearly no effort on the users part now. And the only thing making users think the MicroCash network is the "real" one is simply the fact the client software by default will point to that one. It makes me think of the altcoin situation with Bitcoin except the MicroCash altcoins will be able to connect with each other in a way, even back to MicroCash itself. This has nothing to do with the sidechains that are possible in MicroCash, it is literally the capacity to have another peer to peer network with its own sets of rules merely extended from MC that can be read and understood by MC. A bit fascinating in a philosophical kind of way.
    Last edited: Feb 17, 2016

    IWILLBUYALL New Member

    Has any thought been put into building off of the Hyperledger fabric that IBM has released recently? It will be good to build off the same fabric as that, as I imagine future blockchains will do the same - if that's possible at this point of course.
  12. Ryler Sturden

    Ryler Sturden Member Staff Member MC Developer

    Thanks for the link, I couldn't find a white paper or anything of that nature , do you have a link to one? Projects like hyperledger will start to open business to the concept of the open ledger that Bitcoin and MicroCash use. Which is a very good principle. I have been reading a couple other big business distributed systems like Dynamo that Amazon uses, read their white paper if you have the time - it came out before Bitcoin. https://en.wikipedia.org/wiki/Dynamo_(storage_system)

    As to whether MC can build off that fabric or not, it is hard to say. I feel like the technology in MicroCash can be used for anything. It is hard to see hyperledger beating MicroCash on any aspect except marketing. That may be a bold claim but the actual tech in MicroCash is not limited to currency and I have been involved in this community as a low level developer longer than most as well as P2P in general for over 15 years. I have actual working code and care about efficiency for the transactions (which is the foundation everything else relies on). If I was them I would simply fork MicroCash when released because outside some niggling changes they may want to make I highly doubt anything they do will be competitive.

    Will they? Probably not. Should they? Yes. The reality is, since MC Will be free, including source code, we should encourage everyone and anyone to use it in whatever way they want. The use of such technology will be good for the world as it will force drastic change to the current corrupt and broken system. Like I said in my above post it is possible for others to use MicroCash out the box for many different projects without changing a single line of source code, some examples would be a secured p2p relational database or a secure instant messaging system.

    I designed MC to be very modular so you can rip out the parts you want, slot in new ones, without much effort at all. It is not like Bitcoin which is very tied to how Bitcoin does things, which is why things like running multiple nodes is easy - even if they have different rules.
    Last edited: Feb 18, 2016
  13. Ryler Sturden

    Ryler Sturden Member Staff Member MC Developer

    I have been doing more work on the transaction and account systems. I have also been improving the efficiency of a couple of the main crypto algorithms. The biggest leap which is in EDDSA , the public key cryptography aspect which underpins all the account and transaction security.

    The old code was doing about 2500 transactions per second on a 3.5GHz I7 with 8 threads. Which is roughly Visa volume. The new code is over 16000 transactions per second on the same hardware which is roughly VISA x 6. This isn't accounting for any of the network and account overhead, so expect the real number to be about 5-10% less than this, but it is still very impressive. And the best thing is it can be optimized even more - but I won't be doing any more just now because the number is already so high. A couple GPU guys are looking into making an OpenCL and Cuda version that MicroCash can use so that we can handle even more if a GPU is available.

    As it stands now bitcoin is doing about 3-5 transactions per second and as everyone knows is struggling very badly. Hopefully they can sort that out soon.
  14. fellow

    fellow Member

    the gpu options sound interesting.
    i always wondered why the nvidia quadro series offers ecc memory.
    even if it cannot detect all bit flips i would absolutely recommend to use ecc if the load requires it (bitflips happen more often than people think they do, even on sata transmissions).
  15. Ryler Sturden

    Ryler Sturden Member Staff Member MC Developer

    I've used ECC and would recommend it whenever data reliability is paramount. Strangely I've never found a memory problem in non ECC memory unless overclocking was involved and the system was unstable. It is a scary thing to think about as a programmer, the reliability of your programs memory because one bit being flipped somewhere and the whole thing can be destroyed. Thankfully nearly everything in crypto land that is important is verified with crypto and hashes but some aspects still have to be in that "can never fail" zone.

    Which reminds me I should probably add a memory check option to MicroCash which clones every memory buffer and tests them for differences to detect such memory errors. Some nodes may want to run in this mode always.
  16. fellow

    fellow Member

    not sure if it is possible with a reasonable amount of workload or already done differently but i think it is also a good idea to optionally extend such integrity checks to the stored data on hdd or whatever storage device will be used in future.
    i know this should be part of the filesystem which provides the data but except for a specific configured zfs and some exotic other filesystems it is almost impossible to 100% rely on what the blockdevices deliver (i am sure most windows users had experienced some time a bluescreen while the "system was heavily in swap" or people verifying their raids see on regular base corrected errors).
    all this is caused by the theoretical bit error rate of 10^15 for sata (every 113tb) and even sas is not much more reliable (10^16).
    all this happens on regular base but most time you do not recognize it happens.

    a feature to detect such errors i would tag as "nice to have" if there are more important things to be done first.
    however, i just googled what the BER index for ssds is. i found a kingston best practice link and they have the topic endurance at the bottom of the page comparing different lithography techniques. there they state for the nand gates a BER between 10^4 and 10^9.
    all this may be somehow be seen in relation with the ssd bios features but they clearly state there occours a hardware originated bitflip every 10^7 bit (1.2gb) for mlc drives.
    this means a integrity check feature for the stored data is a absolutely must have in my oppinion.
  17. Ryler Sturden

    Ryler Sturden Member Staff Member MC Developer

    Actually I haven't done the state and transaction writing yet. But it will have to all be verified to some extent anyhow. The financial state is very important and the node should not run until it is 100% verified.

    Unlike Bitcoin this is a relatively fast process so can happen every startup.
  18. Ryler Sturden

    Ryler Sturden Member Staff Member MC Developer

    I've been working on the UDP engine of MicroCash. It was nearly all written by Michael Lanthros so thanks go to him for that effort. I wanted to actually rewrite it to use ASIO like the web server as it would remove some platform dependent code, however doing some benchmarks I found out that its performance wasn't very good compared to what Michael wrote. However there are a few areas of improvement over Michael's engine that I will be implementing.

    He had the UDP socket code in a single thread, handling read and write functions in an asynchronous nature. This is pretty good performance do not get me wrong. I will be moving it to two threads, synchronous, with READ and WRITE happening in two separate threads. This will remove the ~5ms delay he had on all UDP writes and generally double the UDP throughput by making it full duplex in nature. So now reads and writes will be near instant, which is important for latency issues. 5ms doesn't sound like much but it does add up in a P2P network. I don't want to criticize his work too much because it generally is pretty good so sorry if it comes across that way.

Share This Page