I would like to know the technical reasons of why you choosed your universal divedend coin to be a blockchain fiat currency, and not a mutual credit.
For those who dont know what a mutual credit is, read here:
Let me copy paste an explanatory quote from the above white paper.
Most people think that money is just money, but there are literally hundreds of decisions you can make in designing a currency to target particular needs, niches, communities or patterns of flow. Some seemingly small decisions end up having large effects when iterated over centuries and billions of transactions. But, for the moment, let’s just stick to one core design principle regarding how units in a currency are issued.
Blockchain cryptocurrencies are fiat currencies. They create tokens or coins from nothing. Bitcoin does this through mining, allowing the miner who completes a complex processing task first, to commit the next block of transactions to the chain along with a transaction that creates a bunch of new coins. These coins are just “spoken into being” (the meaning of “fiat” in Latin) by the node committing the new block. Thus begins the challenging task of tracking all the coins that exist to ensure there is no counterfeiting or double-spending. You wouldn’t need to manage consensus about whether a cryptocoin is spent, if your system created accounts which have normal balances based on summing their transactions. Sounds simple, right?
There’s a name for this completely peer-to-peer approach to issuing managing a currency supply: mutual credit. In a mutual credit system, units of currency are issued when a participant extends credit to another user in a standard spending transaction. Picture a new mutual credit currency with all accounts having a zero balance. The first transaction could look like this: Alice pays Bob 20 credits for a haircut. Alice’s account now has -20, and Bob’s has +20.
Notice the net number units in the system remains zero, just like the balance sheet in standard accounting must always balance to zero. That accounting practice places no limits on the amount of cash or assets a business can have; it simply means they are offset by an equal amount of liabilities or equity. Every negative balance in a mutual credit system is offset by positive balances so there is always a systemwide ZERO balance. You could think of the total number of units in circulation at any time as the sum of all the negative balances (or, if you prefer, the sum of positive balances since they are the same number).
But wait — Alice spent credits she didn’t have! True. That’s exactly how issuance in mutual credit works. Managing the currency supply in a mutual credit system is about managing credit limits — how far people can spend into a negative balance. Different systems set different rules about this, ranging from everyone having the same limit (e.g. 100 credits), to having NO limits and leaving the choice up to each person as to whether they want to extend more credit to someone deep in debt. It really depends on the community, the relationships, and the use case.
One elegant approach to managing mutual credit limits is to set them based on actual demand. You can calculate credit limits to be an equivalent of what you can pay back in 3 months (or another arbitrary period) based on the transaction history of each account (with a couple of anti-gaming modifications). This allows the currency supply to expand and contract based on the actual usage patterns of the community which demonstrate the market demand for the value people are providing.
This raises concerns about manufacturing fake accounts to game credit limits (Sybil Attacks). However, it is easy to implement different classes of accounts. Easy to create, anonymous accounts may get zero credit limit, only able to spend credits which they have received in prior transactions. To qualify for an account with a credit limit, one may need to validate their identity, pay an application fee, or jump through whatever hoops the community decides are appropriate for the community to extend credit (e.g. be a member of the church, live in the neighborhood, have placed a security deposit, confirmed a credit card on file which can be charged for fraud, for example).
What if I alter my code to give myself an unlimited credit limit, then spend as much as I want? As soon as you pass the credit limit encoded in the shared agreements, the next person you transact with will discover you’re in an invalid state and refuse the transaction. But what if they don’t want to refuse a transaction just because I’ve entered an invalid state? If two people collude to commit an illegal transaction by both hacking their code to allow a normally invalid state, the same pattern still holds. The next person they try to transact with using untampered code will detect the problem and decline to transact. If you get everybody to collude with a new agreement, that is comparable to a new software version or soft-fork of a blockchain.
Most modern community currency systems have been implemented as mutual credit, but we don’t know of anyone who has built a tokenless crypto-mutual-credit-currency yet, so let’s outline an approach to creating a basic one with minimal supporting infrastructure.
So why G1 is not a mutual credit? Who rejected the mutual credit initial decision, and for what technical reason? Is the universal dividend incompatible with the mutual credit idea?