[DAB, printing rules] How about fuduciary money?

Hi everyone,

Has seen in different Q&A after conferences about free currency, one recurrent question is about the possibility to get fuduciary money (ak paper or coin money) for people without an electronic device and/or without an internet connection.

I think the question is important to answer as a good monetary system must respect the 4th foundamental economic freedom that is : Freedom to exchange in the money.
(see http://pjc76.free.fr/conf/ [fr] slides and the III.2 one )

I think this means that a fiduciary form of a free currency must exist to ease the adoption of free money to disconnected people.

So I open the discussion about the need and the possibility to get fiduciary version of a OpenUDC free money.

Theory about fiduciary money

  • It is not the main representation of money: scriptural money (digital) must be kept the main .
  • It is a physical token (paper printed, coin) representing an amout of scriptural money (digital account).
    • The digital amout is “locked” and can’t be exchanged since the token exists and is exchangeable.
    • The token can be destroyed, then the digital counterpart of money is “unlocked” and exchangeable again.
  • It have to be securised for people to trust it as the digital system counterpart.
    • Uniqueness: it can’t be duplicated as several representation of the same digital amout occur.
    • The amout of digital amout counterpart can be verified before each physical transaction.
    • The amout of digital amout counterpart must be verified without digital and/or connected device/tools.

(this list of theorical ideas can be updated, feel free to contribute)

This is possible. Any company or association can propose to exchange some blocked electronic units against some paper or coins that will be able to be exchanged back against the blocked units.

So it is not a problem, just do it.

Of course, the discussion here is how it can be connected to a uCoin currency, for people and developpers to find a way to create it.

I wont do this alone @Galuel

The goal here is also to think about a system that wont be the reponsability of just a company, but the possibility of each currency user (as the money creation is).
Therefore, like OpenUDC define rules proposition to communicate in a TRM currency system, we chould think about a “token convertion protocol” to garanty no one can take advantate with its special way of tokenize OpenUDC money.

Just do it, and propose it to future users. Then if it is ok, probably they will adopt it.

My first idea is to create a token containing a QRcode corresponding to a transaction “into the void”.
The transaction is between one account to a special account where the amout of money is stocked.
One reference code translated into a QRcode (witch can be printed, painted, or whatever).
The printed QRcode is exchanged IRL to mesure some value exchange.
And then one day the QRcode is used by an app to transfert the amount from the special account to a normal account.
Then the token should be destroyed. It could be destroyed only by code validity. If the special account contain the transaction QRcode it can be tranfered into the account. The second time the QRcode is scaned, the transaction is already “gone” so the token is useless it can betroyed.

The token should be also scanned by a verification app, that check the validity by asking the special account about the transaction, if it’s still there or not.

Galuel it’s what I’m doing! Useless comment…

The developper side of this discussion is:

  • First people who well knows the OpenUDC protocol may validate the possibility of a special account and/or transaction type creation?
  • A QRcode content format should be defined as every DAB device connected to uCoin network should work the same to permit an equity about money tokenization process.

The print securation policy could be left to user/association/company.
By exemple a method when QRcode is read need the token destruction. Like 1 layer contain printed QRcode and a protection layer above it so that you need to separate the 2 to scan the QRcode.

I’m not sure to understand your proposal very well, but you should think about a possible protocol using new ucoin 0.2 transaction rules :
https://github.com/ucoin-io/ucoin/blob/master/doc/Protocol.md#transaction

The mecanism with the XHX and Locktime parameters should be especially useful to build a DAB system.

The most difficult problem is the fact that the bill could be exchanged while being invalid. I guess, if it is simple enough to check the bill validity with a connection, people could trust the system if the company behind the bill is trustable ?

I’m sorry but the protocol documents are a bit confuse to me. So could you please @Inso, resume the mecanism with the XHX and Locktime parameters? For me to undestand.

Just a note: OpenUDC project is in a vegetative state since 2 years. Here we develop uCoin.

IMHO the whole problem in such a system is that at some moment, someone knows the unlocking password. So we always have a third party in which we must have some trust.

That’s why a company, association or even an individual is necessary to issue the paper money and be trusted all the way during the paper existence: from the issuer of the paper to the last user which will consume the actual coins behind the paper.[quote=“devingfx, post:10, topic:759”]
I’m sorry but the protocol documents are a bit confuse to me. So could you please @Inso, resume the mecanism with the XHX and Locktime parameters? For me to undestand.
[/quote]

Yes these documents are a bit confusing I admit :slight_smile: Here is a Bitcoin explanation about crosschain transactions, which might be an help toward paper money.

Basically, with ucoin protocol 0.2, transactions are locked by condition. When you receive some money, to consume it you have to pass parameters which unlocks the conditions.

So, when you send a simple transaction to someone, you lock the transaction with a"SIG" condition which means : to consume this transaction, the receiver has to sign the consuming transaction with his pubkey.

The XHX conditions is a conditions which means : here is a hash, to consume this transaction, you have to pass a XHX parameters (a number) which, when hashed, generates the same hash.

This way, only the one who knows the number can consume the transaction.

The locktime parameter is something else, which means “this transaction cannot be written in the blockchain before X seconds”

There is no limit in the number of conditions locking a transaction.

I guess this could be explained in a blog post with some possibilities of this system? :slight_smile:

The goal of this discussion, I hope, is to find a way to eliminate the trusted third party (or make the network the third party).

Can be a transaction locked several time? And can the condition to consume it be written in a QRcode ?

There can be multiple SIG or XHX locks conditions on a transaction. They can be combined with “AND” and “OR”.

You should take a look at the examples in the protocol page :slight_smile:

Then I insist for you to have a look at crosschain transactions. Just to give you an idea, it allows:

  • to trade coins of 2 different currencies with 2 different people
  • without any third party (but the technical networks)
  • without any trust between the 2 people exchanging

This is already implemented in uCoin, we just need clients (like Sakia/uCoinApp) to be compliant too.

Another less technical explanation is given by http://mercuryex.com, “Atomic Swap Protocol” section.

Ok I merely understood Atomic Swap Protocol, as being bidirectional deposits, then deposits are exchanged only if the 2 parties did signed and resolved with condition the “later” transaction.

Here the QRcode tokens should be created without a destination public key, and the transaction locked “for infinite amount of time” until a public key consume the transaction, then the QRcode token should be unusable.

The QRcode token will be exchanged freely between creation and destruction without the need of the blockchain.

Can you explain using the SIG and XHX conditions with an example please ?