Economic decisions and address improvement

Image1The last few days I spent putting together the 2 alphas and disk access. I have a single thread which writes out to disk to avoid any locking issues and which allows the main worker threads to be running full speed without worrying about slow disk access. In Bitcoin disk access is involved in nearly everything when it comes to transactions which makes the engine very slow in comparison. I have also been brainstorming a bit more in regards to the MicroCash addresses and I am interested in what other people think.


Previously I discussed the new look MicroCash addresses which would look like this NNGU-YKWW-Z5I3-YGB3Y . Contained within is an 80bit hash of your public key, similar to Bitcoin except the hashing is different and size is half as much (160bits in Bitcoin). In case you are wondering if 80bits is enough for a hash the answer is yes. 2^80 is quite a space to bruteforce and it only applies to before an MicroCash account is registered.

So if someone sent you 10MC to a new address and for whatever reason you failed to run a client which accepted that for a week, then an attacker would need to bruteforce the 80bits within a week. For most people who send to a new address they will typically be at their computer/phone/whatever the moment they send it and it will be registered immediately. Either way the attack vector is nearly impossible even if you waited a year, let alone were cautious and did it immediately so it’s no point in worrying too much about it.

Anyhow….. I had an idea, what if we changed the addresses to look like this – MCASH-NNGU-YKWW-Z5I3-YGB3Y . Basically just added the MCASH to it right? Nothing special there? Well actually the “CASH” part of it is actually a text identifier to a specific balance ledger. Let us consider that the CASH ledger is the default MicroCash one , so if someone posts something starting with MCASH we know where it is supposed to go. But what if we allow users to create their own ledgers within MicroCash for a fee? Want to start one called BTC? MBTC-NNGU-YKWW-Z5I3-YGB3Y . Or what about USD 🙂 ? MUSD-NNGU-YKWW-Z5I3-YGB3Y .

So if we can select which balance ledger a transaction is going to then it would also be cool if the person who creates them could create specific rules for each ledger. Maybe they only want 10 of their currency to be created because it is for a specific private purpose like family trust . Maybe they want to increase currency based on Proof of Work mining, etc.

And on top of this what if we have a default commodity for MicroCash too? MicroGold ? MGOLD-NNGU-YKWW-Z5I3-YGB3Y . This also means we could have a decentralized exchange built into MicroCash to trade all these other ledgers into MicroCash, you wouldn’t even need a centralized exchange to do it.

Proof of stake coins mostly have a fixed rise in their currency, like 3% per year. I was thinking instead of MicroCash itself merely rising 3% per year (or whatever) that it may be more smart to let MicroGold dictate that based on a decentralized floating exchange rate. So the MicroGold aspect is kind of like a decentralized Government bond system.

But even though this sounds good in theory to me how it would work exactly is twisting my neurons so if anyone has some ideas about how to increase and decrease the MicroCash economy then please comment! Thank you and thanks to everyone who run the alphas and passed along the performance stats.

Advertisements

13 thoughts on “Economic decisions and address improvement

  1. SC holder says:

    The idea of pegging mc to gold is not a new one. It was proposed for maxcoin as well, but incompetence and unwillingness to actually go through with it stopped it.

    I wonder how you propose to peg it though? where will you draw the value from? An international gold exchange? Or several? And will it then be a value based on the dollar?

    In that case you might see an inverse tendency as the dollar starts hyperinflating. Which will not be good either.

    What I assumed, and which got me interested in microcash in the first place was the market scaling. I suggest that all transactions over a certain size are used as a measure for the increase or decrease in money supply. This way actual usage of the coins are determining for inflation. To reduce manipulation of the market by just transferring money back and forth, every transaction should be taxed and the money redistributed proportionally based on market share between every single holder. This taxation should have a plus or minus factor to it, either increasing or reducing total money supply. This would benefit holders as well as posing a negligible problem to users as they can rest assured that their tax payment will not reduce their market share any more than the coins they have actually paid. Market share is the source of wealth and banks and governments constantly erodes this through their interests and taxations (which is not redistributed proportionally).

    Liked by 1 person

  2. Bigrah says:

    In my opinion MCASH- (or any other lige micro(xxxx)cash is really needed. So you can see at one look what it is and dont have to guess..

    Like

    • IMHO, this is mostly unnecessary as a requirement but could be a good *standard*. When the final value of the address is derived, the “MCASH-” or “micro(…)cash” portions of the text address will be stripped away. I think something as simple as “MC-” could work or, better, allow addresses of various formats. For instance, straight, numerical representations could be nice. I’ve always enjoyed making low-number vanitygens and I would be farming a 7-8 digit address, for sure. B-)

      Liked by 1 person

  3. Hey Michael, I’m sure you have no clue who I am but I’m RLH (! was on the Microcash forum and I still am on Bitcointalk. PM me to verify.) Anyway, I was an early “Solidcoiner” and contributed significantly to the Microcash discussions regarding mechanics and fiscal mathematics up until the point where, well, RS went AWOL on the project in order to run his exchange.

    I’ve been following your work and I’ve waited to respond (for a few reasons.) However, after not speaking with any former SC/MC enthusiast for a LONG time, Notyep contacted me and asked me to take a look at this post.

    SC Holder is correct. The initial hope/intent was that MC would have an “inflation rate” that was derived from the activity of the network. In fact, I spent a TON of time coming up with such an algorithm and if I find some time today, I’ll see if I can find those old notes which I posted on the forum. If you PM me in BTT, send me an email and we can discuss and I can send along my old notes.

    Of course, constant inflation isn’t always good (inspite of what many economists try to argue.) In such a circumstance where too much supply is in existence, supply is decreased through daily fees. Specifically, if I recall correctly, all daily and transactional fees were “lost”. In other words, fees wouldn’t go to node operators or any form of miners. This meant that if far too much supply existed, over time, fees would drain the supply and valuation would increase, per unit (Microcash Dollar.)

    Anyway, please, PLEASE, do not peg this coin to either a fixed inflationary rate or, even worse, some real world asset. It doesn’t have to be that way and with a proper analytical algorithm, you don’t need it. Plus, pegging to another asset means that your system isn’t “closed” and will forever need to rely on a single, agreed upon, “trusted” source.

    Anyway, if you are interested in advice, or discussing this further with someone who spent years caring about this project before moving on, please send a PM my way on BTT.

    PS: Regarding assets/colored coins/etc, personally, I’m opposed. These exist in other coins and, frankly, being another coin with an internal exchange could cheapen the amazing features of Microcash that are new and worth paying attention too.

    Internal exchanges aren’t expected with new coins but, IMHO, this shifts the focus from their actual purpose– to act as a currency. Furthermore, if you integrate a good, internal system for growing/shrinking supply, this could have detrimental effects on asset pricing, especially in the early days where interest rates me fluctuate.

    However, in time, if the community wants such a feature, it could be added later. For now, however, I’d suggest avoiding the internal exchange.

    PPS: After missing the old days of Microcash, I’ll admit, I started working on my own version of “Microcash” which I was going to call something else. I wasn’t, however, going to even mention it until it was completed because I don’t like long, drawn out IPOs that don’t see a product (and often a poor one) until months after the funds were raised. My project was/is only about 20% complete so I’ll probably scrap it. It was a fun exercise, but there is no need for it now.

    There is more that I can say, but I’ll try to keep this simple. Yes, this is simple for me. Brevity is not a talent that I possess. 😛

    Liked by 1 person

  4. SC holder 2 says:

    I agree with the comment from SC holder. It seems reasonable that inflation/deflation should be based on the velocity of MCASH – this is the only thing mcash network knows for sure. I did not get the whole idea of decentralized exchange. Why would people by MGOLD or whatever else MSHIT? Where is the value coming from?

    The points that SC holder is rising are valid in my mind. I am a bit cautious that the system he suggests would be a bit deflationary, as there seems to be an incentive to save rather than spend, however it’s much better in this terms than BTC and share-based distribution is fair.

    Where do we set the cut-off though? Say if less than 1% (a totally out of the blue number) of coins are transferred, we inflate, more, we deflate.

    P.S. This is my first post here and I just wanted to say how wonderful it is to see great development efforts on mcash.

    Like

  5. Notyep says:

    Good comments! I feel in order to get a handle on how the MC economy will move, we must first quantify its beginnings. In other words, how will the initial market share be established (will it solely be based on the amount of existing +2M SC (solidcoin) currently in existence or will an additional amount be introduced into the MC network based upon some other attribute such as mining or initial exploded interest rate on balances)? I like the MicroGold/commodity concept to back MC since commodities such as gold serve as the foundation of global currency and always has. In any case, I feel if we address the beginnings of MC first, the questions of how MC will thrive can be easily answered.

    Like

  6. callmejack says:

    in general i dislike the idea to be able to adjust the total supply of any coin but in terms of growth and “lost coins in the network” there have to be some options for “adjustments”.
    using any external data sources as reference to dynamically adjust any coin settings is a really interesting idea which works as long as these sources are reliable over years.
    therefore i would go with a network internal design.
    i really like playing with numbers. i could imagine to set the initial supply to x MC and then build a factor to regulate the supply based on how much cash got moved during a defined amount of time and number of transactions. this factor shall increase the supply if “too much” got moved (people want more) and reduce it if “too few” got moved.
    if people park their holdings on exchanges and move it only virtually the supply would get automatically reduced over time.
    once there exist services payed in MC exchanges are only a gateway to fiat and the internal ecosystem adjusts the coin supply robotic like without relying on external data.

    Like

  7. SC holder 2 says:

    Well if the moneys are moving less, in a healthy economy it would probably mean that moneys are worth more – so for the same amount of goods and services you need to move (pay) less money – so supply needs to be INCREASED to avoid deflation.
    If “to much” got moved, then perhaps it’s because the currency is worth less, so we should decrease monetary supply, not increase it. The catch is that at the beginning not a lot of coins are moved due 0 economy behind a crypto, so we should cap maximum inflation/deflation at, say 3% a year and calculate moving averages over a year to take decisions on if we should inflate/deflate, meaning that for the first year of mc there will be no inflation (or a fixed one for the first year if you deem this appropriate).

    On the side note, I agree with RLH, it was fun discussing MC back then few years ago. It’s a total shame that the forum is now unavailable and tons of very nice and helpful comments got lost. A cypto is economy + code and both have to be sorted out from the start. A good code + a bad economy = fail.

    Adjusting monetary supply based on money velocity may not be the best idea, but I can’t think of anything better now. We just need to sort out the numbers right and we’d better do it in the best possible way.

    Foxit

    Liked by 1 person

  8. Notyep says:

    “Also, it’s expensive. Attaching PINs to credit cards is an extra batch of data running along the credit card network. That tiny addition requires a multi-billion dollar software upgrade at credit card companies, banks, makers of payment terminals and merchants, experts say.”

    This quote was taken from a Wal-mart exec discussing what he claims to be one the major pitfalls in the upcoming Visa/MC upgrade (lack of PIN #s associated with new “chip-based” credit cards (see link below). Come on, a “multi-billion” dollar software upgrade? Give me a break! Wait until these retail/credit card execs see what Microcash can do. 😉

    http://money.cnn.com/2015/04/03/technology/walmart-credit-card/index.html

    Like

  9. Cluck says:

    no news are good news…???

    Like

  10. Cluck says:

    microcash.org expired… bad signs 😦

    Like

    • Notyep says:

      Keep tabs on microcashnews.com which is relatively new. SuperTramp is getting it positioned to be one the premier sites for announcements/updates…

      Like

Comments are closed.

%d bloggers like this: