Topic: UUID Coin (brainstorming a new kind of coin that doesn't need a block chain) (Read 4453 times)

Interesting thought - will mull that one over and see how that might be able to work.

Okay then think about this:

Many people *owe* money the whole of their life and are working to constantly pay off loans.

What difference does it matter to these people whether the coins last more than 69 days when they are living from paycheck to paycheck?

(and yes it isn't a "store of value" coin so is not intended as any sort of *replacement* for Bitcoin/gold/etc. but could be useful in order to perhaps more anonymously purchase those)

This isn't going to work.

OK, so a coin that expires in 69 days? I could see its usefulness for something like spam control. However unless you have the lifespan of a gnat it isn't going to work as a store of value and no one would accept it as such.

How about..

The Difficulty of the Proof of work IS the value of the coin..

That way, someone on their phone, could create a coin, with a low difficulty and give it to someone. Not worth a lot..

Someone with a large mega-computer, could go for a much harder difficulty coin, and thus it would be worth more.

That way.. The proof of work for the coin PROVES the amount of power used to make the coin and cannot be faked..

The more power used, the more valuable the coin.

[ Just Brainstorming here..  ]

Yes - the idea is not P2P in the way that Bitcoin or Bittorrent is but "node to node" (i.e. a direct interaction between two nodes).

This would mean that 2 individuals could exchange coins while stuck in the middle of the desert without being connected to the InterWEB ?
 
Since the UUID of the coin IS the coin you don't need mass miner authentication..

That's a nice feature.

Yes - the idea is to fit in with regular income and payments (such as rent and other bills) rather than being a long term "store of value" (this concept is not aimed at replacing Bitcoin or gold for that matter but instead to provide a far more untraceable system of transferring relatively small amounts of "money").


Not sure at this stage (this is something that would need to be worked out - it could initially simply be hard-coded into the software).


As stated - it is "brainstorming" how something *without* a block chain could work (and this idea may not work although I don't think you've managed to kill it so far).

So - You MUST SPEND all coins within 69 days of their creation ?

And after that the COIN is no longer useable ?

What determines the difficulty of the proof of work required to create a coin ?

I really like the idea of an actual COIN, the UUID, but cannot see how the system can survive if there is no ledger..

The most obvious problem I can see with the idea is that someone could simply "publish" a transaction (making it then unusable for re-spending assuming others add all the "coins" to their collection of "extra coins") although perhaps "social networking" would help identify the "cheaters" so others would not do transactions with them again.

This is just some brainstorming and therefore may well be fundamentally flawed (which is why I am posting this as I know the many smart minds here will quickly find an obvious mistake) but I think in light of the recent emphasis that seems to being made on using the block chain to "trace coins" (be it for white, black, red or some sort of glow in the dark list) we need to try and think outside the "block chain box".

UUID Coin

Each payment requires a "proof of work" for a UUID which is sent to the payer by the payee. The proof of work is known as the "main coin" and is worth 100% of a UUID Coin unit (XUC?). Each payment can also contain one or more previously mined or obtained UUID Coins with the caveat the receiver will not accept coins whose UUID it has already recorded along with the "when" mined timestamp.

The "proof of work" algorithm needs to be one that requires a large amount of memory to favour CPU mining (so the algorithm developed for Protoshares could be the most suitable one to use).

struct UUID_Coin
{
   uuid;
   when;
   nonce;
};

to verify a coin simply check that:
pow( uuid + when + nonce ) >= "accepted difficulty"

struct Payment
{
   UUID_Coin main_coin;
   vector< UUID_Coin > extra_coins;
};

The "main coin" is considered as a single unit whilst "extra coins" are fractional units each no greater than 25% of a "main coin" and whose "weighting" diminishes logarithmically according to time.

Consider the following situation:
[UUID] f1049258d8a0e849a6b93e9b09df6df7

mines the following:
2013-12-01 09:00 (f1049258d8a0e849a6b93e9b09df6df7)
2013-12-01 09:05 (f1049258d8a0e849a6b93e9b09df6df7)
2013-12-01 09:10 (f1049258d8a0e849a6b93e9b09df6df7)
2013-12-01 09:15 (f1049258d8a0e849a6b93e9b09df6df7)
2013-12-01 09:20 (f1049258d8a0e849a6b93e9b09df6df7)
2013-12-01 09:25 (f1049258d8a0e849a6b93e9b09df6df7)

then wishes to send 2 coins to 2d5912e43aeb3645ab8d303a661b245d at 2013-12-01 09:30 - first they would mine a new "main coin":
2013-12-01 09:30 (2d5912e43aeb3645ab8d303a661b245d)

then they would add previously mined coins as "extra coins". Let's assume that the value of these extra coins is measured according to the following table:

[coin age]           [coin value]
0..99 minutes        25%
100..999 minutes     5%
1000..9999 minutes   1%
10000..99999 minutes 0.25%

then the entire set of coins sent would be:
2013-12-01 09:30 (2d5912e43aeb3645ab8d303a661b245d) (100%)
2013-12-01 09:25 (f1049258d8a0e849a6b93e9b09df6df7) (25%)
2013-12-01 09:15 (f1049258d8a0e849a6b93e9b09df6df7) (25%)
2013-12-01 09:10 (f1049258d8a0e849a6b93e9b09df6df7) (25%)
2013-12-01 09:05 (f1049258d8a0e849a6b93e9b09df6df7) (25%)

Any coin older than 99999 minutes will be rejected (with the age to be taken from the "main coin" which would need to be no more than 10 minutes old according to NNTP). Also any coin whose UUID and timestamp was already sent to the payee previously would be rejected.

Double Spends

UUID Coin does not attempt to prevent "double spends" as it is not a ledger system. Every spend needs a newly created "main coin" so it is not without cost to perform multiple spends although clearly the more that coins can be spent the better. Although "double spends" per se are not prevented each peer will reject any coins it has already been sent.

Winners and Losers

As coins only last for 69 odd days they simply cannot be "hoarded" but must be used (and the quicker that one can use them the better). As mining uses CPU time it is clearly more profitable to receive coins which others have mined on your behalf rather than to mine them yourself.

Note that coins that are near their expiry are not going to be desirable to receive but are desirable to send so there might need to be some sort of "negotiation" settings (able to be tweaked via the UI) before allowing a transaction to occur.

In order to prevent a receiver from denying receipt of a transaction it is suggested that the nonce values be encrypted with a random key that is sent after all other transaction data (perhaps after the receipient sends a hash of the entire transaction to confirm no problem occurred in transmission). The key for decryption does not need to be secret and so could be published publicly if the receiver is claiming not to have received it. In the case of receiving an invalid key the parties might resort to publishing the entire transaction so that others can verify its validity*.

Please feel free to rip the idea to shreds but if you think that the idea has some merit but needs improvement then please suggest improvements (which I will likely add as edits into the OP).

* this would unfortunately make all the "coins" in such a transaction useless for re-spending as anyone could add them to their list of "extra coins"