Virtual currency without block chain

[Anders]

There have been a few occasions when a trusted CA certificates were compromised and had to be revoked by all browsers. Would that compromise a coins security if it was dependent on CAs?

I don't know but it sounds like a dangerous risk. And even if that wasn't a problem, there would still be the problem of having to rely on third party authorities. Even if only one big trusted authority was used, like VeriSign, there would be the problem of only "elite" nodes being able to operate since the big trusted authority would have monopoly on certificates and could demand obscene amounts of money for licenses. And even with healthy competition among several certificate providers they would have to charge quite a lot of money anyway since they would need to have rigorous control procedures for those who they sold licenses to. And personally I wouldn't even trust a big so-called "trusted" central authority, at least not for a system that's meant to remain robust for centuries.

[Magic8Ball]

Blockless blockchain is possible, but locks are necessary to reduce transaction size. If that was not there, each transaction will take all the data with it and it will be bloated soon.

[Anders]

Blockless blockchain is possible, but locks are necessary to reduce transaction size. If that was not there, each transaction will take all the data with it and it will be bloated soon.

Bloat can be dealt with since disk space and communication speed follow an exponential progress similar to Moore's law. But what about transaction speeds? Paying for a coffee at Starbucks should only take a few seconds at most. 0-confirmation transactions or payment channels can solve that problem for coins with a block chain. It would be better though if the real transactions would be fast.

[Magic8Ball]

Blockless blockchain is possible, but locks are necessary to reduce transaction size. If that was not there, each transaction will take all the data with it and it will be bloated soon.

Bloat can be dealt with since disk space and communication speed follow an exponential progress similar to Moore's law. But what about transaction speeds? Paying for a coffee at Starbucks should only take a few seconds at most. 0-confirmation transactions or payment channels can solve that problem for coins with a block chain. It would be better though if the real transactions would be fast.

We are talking of orders higher bloat, and that will increase with more transactions. In effect we are talking of a system where each transaction is a block. Its nearly instantaneous as the block is created whenever it transacts, but the size will be huge.

[HunterMinerCrafter]

the double spend and counterfeit problems are solved, yet the problem of ensuring consistent data in the DHT remains to be solved.

One of the key realizations to be had is that these are essentially the same concern.

(The coins in my proposal are minted by a central authority but after having been minted the coins are fully decentralized and peer-to-peer.)

Also (arguably) undesirable, for many good reasons.

[TinEye]

the double spend and counterfeit problems are solved, yet the problem of ensuring consistent data in the DHT remains to be solved.

One of the key realizations to be had is that these are essentially the same concern.

(The coins in my proposal are minted by a central authority but after having been minted the coins are fully decentralized and peer-to-peer.)

Also (arguably) undesirable, for many good reasons.

So just Ripple. Minted by a central authority, maintained by a few trusted nodes of their own. Changing their marketcap whenever they feel like it.

[HunterMinerCrafter]

But what about transaction speeds? Paying for a coffee at Starbucks should only take a few seconds at most. 0-confirmation transactions or...

Another of the key realizations to be had is that security can't actually be made to happen any faster.  (Despite what most alts would have you believe.)  There is no such thing as a secure "0-confirmation transaction" or "instant send" because it eliminates the very thing that creates security over the transaction, that being the passing of time.

It is easy for us to forget that Bitcoin is not really, at heart, a system of money.  It is a system of measuring the time passed since "some event" was logged by the network.  It is designed to measure a probabilistic hour in ten minute average increments.

Let's look at two hypothetical networks.  Network A is like BTC, with 10 minute blocks and 6 confirmations recommended for maximum security.  Network B is a "fast coin" with one minute blocks and 10 confirms.

Let's say both networks have exactly the same average hash-rate, the same number of identical processors hashing on each.  The precise number chosen doesn't matter for the thought experiment, as long as the networks are physically equivalent.

I receive a coin on network A and a coin on network B.  Then an hour passes.  Which coin is more secured?

The answer is, of course, neither.  They both have exactly the same amount of security behind them.  The same amount of work was put behind both by now, that being whatever the network can provide in one hour.  No more, no less, regardless of the block interval or "suggested" confirms

Satoshi et al advised 6 blocks of 10 minutes.  One hour.  Regardless of your alt-coin parameters you can't get this much security by any means that doesn't involve waiting, on average, one hour.  You just simply can't magic the network into being able to add  "an average hours' worth of security" in anything less than one hour.

The only amount of security that you can get from 0 time passing is none at all.

[Anders]

the double spend and counterfeit problems are solved, yet the problem of ensuring consistent data in the DHT remains to be solved.

One of the key realizations to be had is that these are essentially the same concern.

(The coins in my proposal are minted by a central authority but after having been minted the coins are fully decentralized and peer-to-peer.)

Also (arguably) undesirable, for many good reasons.

So just Ripple. Minted by a central authority, maintained by a few trusted nodes of their own. Changing their marketcap whenever they feel like it.

No, the idea is to have the system without a block chain to be trustless once the coins are in circulation. The central authority would be a government or something like that. For example the U.S. government could issue the virtual currency with the same value as the USD. And then those coins would be like digital peer-to-peer cash with very fast transaction times. And the transactions can have zero transaction fees with servers run by the government as a public service. So it would be a limited use case but it could be used in competition with existing cryptocurrencies.

[Anders]

the double spend and counterfeit problems are solved, yet the problem of ensuring consistent data in the DHT remains to be solved.

One of the key realizations to be had is that these are essentially the same concern.

The double spending problem is completely eliminated by having unique coin IDs and using digital signatures. The worst attack nodes could do would be to mess up the distributed hash table. Admittedly, that has to be solved too but the double spending and counterfeit problems are solved in this way without the need for a block chain.

[Anders]

Hmm... Wait a minute. If a central authority like the U.S. government issued the coins AND run the transaction servers as a public serve then they could use digital signatures even for the nodes in the network with an ordinary distributed hash table implentation. They could issue a bunch of 10 cent, $1, $10, $100, ... and so on coins. Very efficiently and to a small public service cost. The wallets can be digitally signed with a national ID system (a potential Orwellian danger perhaps but anyway) and that would eliminate the need for messy cold storage with paper wallets and all that cumbersome management. That's something for Obama to look into.

[HunterMinerCrafter]

The double spending problem is completely eliminated by having unique coin IDs and using digital signatures. The worst attack nodes could do would be to mess up the distributed hash table.

If you can "mess up" the DHT then you can double spend.  For example, send some coins to an exchange, trade them for btc, then scrub the transaction from the dht (perhaps via Sybil attack) and send the same coins off to some second exchange and sell them again.  Having the coins identified and signed doesn't really help the first exchange.

[Anders]

The double spending problem is completely eliminated by having unique coin IDs and using digital signatures. The worst attack nodes could do would be to mess up the distributed hash table.

If you can "mess up" the DHT then you can double spend.  For example, send some coins to an exchange, trade them for btc, then scrub the transaction from the dht (perhaps via Sybil attack) and send the same coins off to some second exchange and sell them again.  Having the coins identified and signed doesn't really help the first exchange.

You can't replace transactions. The unique ID for a coin makes it stored as a single value. By messing up I mean that an attacker can put wrong information into the DHT or delete information. If the attacker manages to delete a coin and then tries to put it in again with another owner then the digital signature would have to be cracked for that to be a successful attack.

I see what you mean now. There is no complete history for the transactions so an attacker can simply make up a transaction and sign it correctly. Yes, then messing up the DHT can lead to double spend.