Just be sure that you save the web page for "offline" usage (which is the only way you should use this kind of website) and disconnect the internet before using the "offline" version (making sure that it won't somehow get automatically connected when doing so).

You cannot "double-spend" bitcoins - that's what the entire purpose of "confirmations" is about.

It is possible to end up with what you might think of as "double-spends" in the short term (but will never stay that way) although typically that would be before a tx is even confirmed at all (what are known as "0-confirmation" txs).

This is why you want to wait for X number of confirmations before considering a tx as "safe" (the value of X depending upon the value of the tx to you).

Understand that the "longest" link of blocks back to the genesis block (known as the "blockchain") contains exactly ZERO "double-spends" (otherwise Bitcoin would be completely broken).

Sometimes what are called "re-orgs" happen which can replace the latest blocks with a different (you could think of as "superior") set of blocks which is why for greater tx amounts you would be advised to wait for more confirmations (most standard clients consider 6 confirmations enough although maybe if it were a house you were selling you might want to insist upon say 100 confirmations to be more certain no re-org could result in the tx disappearing).

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)

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).

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).

Agreed - also for an idea about a non-block chain coin: https://bitcointalk.org/index.php?topic=334576.0

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"

Have sent some BTC and would be more than happy to set up a project on CIYAM Open for this (free of charge for its lifetime of course).

True but it seems that they have very much differentiated Bitcoin from QQ coin (which was really just one company printing its own money).

Was already discussed in several topics - basically it's really just the >50% attack problem that Bitcoin has always had.

Most welcome - although it takes a bit of getting used to once you've mastered raw transactions you'll never turn back (although hopefully "coin control" will make it into one of the next releases to make easier for others)!

You can use http://blockchain.info/decode-tx (otherwise use the "decoderawtransaction" command with bitcoind).

My understanding (correct me if I am wrong) is that the payment protocol is less than 1000 LoC (so not a huge undertaking) and that it has been designed so that another system (instead of the CA one) can be easily put in place.

I am not a Foundation member nor am I any sort of sycophant of any of the devs but I don't think that they have "lost the plot" at this stage (although I do think that scalability is probably the main thing they should be focused on now).

It was *agreed* to by all the major pools - so I fail to see how that is a dictatorship (unless you include all the major pools as being the dictators).

Well - a good retort (and I know you like to argue) - I think that the model of wasting blockchain space did need to be stopped but for sure maybe it hasn't worked perfectly. As far as "taking down the capitalist" I think that Bitcoin gambling sites are still doing very well.

Best if the offline computer *never* connects to the internet after you decide to use it create secure keys.

In this way you are safe from key logging viruses or the like.

(I actually bought an old laptop and got the WiFi card removed then blocked the ethernet and modem plugs to do just this)

You don't recall all the complaints about SD and people running out of disk space?

It they did nothing about it then I am 100% sure you would be complaining about that now.

Well yes - it was exactly that which I had mentioned - and clearly no-one forced anyone - the pools agreed that the best solution was to go back to the rules of the previous version (the most sensible way it could have been resolved).