--
Charles N Wyble cha...@thewybles.com
(818)280-7059 http://charlesnw.blogspot.com
CTO SocalWiFI.net
Very interesting. It looks like BitCoin has come up with a workable method of
handling distributed financial transactions in a reliable way, something which
is notably lacking in Ripple (the single-node case works great, but as a
network, not so much).
But while the underlying BitCoin architecture is fantastic, they seem to have
made the fatal mistake of trying to create Yet Another Currency, without making
any attempt to address any of the problems of any of the existing currencies.
And not only is the money supply controlled by a central mint (who could decide
to debase the existing currency at any time), but the inflation schedule is
fixed instead of floating freely with user demand, leading to spikes of
inflation when new money is added, followed by periods of deflation as the user
base expands.
I think on this point Ripple gets it exactly right: we don't need another
currency, but a better method of exchanging existing currencies by bridging
between payment networks. This also avoids adding new inflationary problems by
tying the value of virtual payments to real value in the real world. Trying to
use real physical goods would be difficult at best, which is where the
brilliance of social credit comes in - it's finite real-world value that can be
easily represented and verified.
One of the stated goals for Ripple is as an experiment to see how much of
traditional lending by monolithic banks can be replaced by a small loans within
a social credit network. But I would like to see it go further and explore the
necessity for money in general. After all, physical money is just a proxy for
real-world value, and only useful to the extent that it can be traded for such.
I'd be interested in seeing to what extent the ownership of currency can be
optimized-out of transactions, leaving a virtual barter system.
At first glance, this wouldn't be that difficult. If the system is already to
support conversion between debts in terms of any number of arbitrary currencies,
it's not much of a stretch for it to support exchanges in terms of anything that
can be expressed in XML: currencies, commodities, futures, debts, et al. The
users of the system can then declare what articles they are willing to pay with,
and what they are willing to accept. The system then finds a chain of
conversion from what the payer has to what the payee will accept, and ownership
is transfer as in BitCoin.
Thoughts?
-- Steve
Minor disagreement here: I don't believe in "intrinsic value", only intrinsic
properties which may be subjectively valued by quasi-logical Humans. The value
of land/location depends entirely on what purpose it is to be used for (what's
the value of an acre of ocean to someone who has no boat?). The value of energy
depends on it's form and timing (what is the value of a nuclear explosion? to
whom?). And knowledge can have value in the sharing (e.g. Wikipedia), or in the
withholding (e.g. blackmail).
I'm left with the conclusion that the only way to quantify the "value" of
anything is through a free market, and I think a decentralized payment system
should take this into account.
> In each case it is possible for an
> issue of Units redeemable in use value which have a value in a barter
> exchange by reference to some unit of measure or Value Standard.
All expressions of value are relative to standard, but all standards of value
are subjective. Unlike say, feet-per-meter, which is a constant,
dollars-per-yen or euros-per-watt or chickens-per-diesel-gallon all fluctuate
chaotically. Not only should a payment system not assume a constant value
standard (I'm looking at you, Bitcoin), it should assume exactly the opposite
(freely fluctuating value standards).
> This brief critique of Bitcoin is from someone who has many years'
> deep practical experience in the e-money space, particularly on the
> crypto side.
Alas, they have badly misunderstood Bitcoin.
> Well, it is peer to peer rather than client-server. My assumption is
> that a server needs to run the money, which is tightly coupled to an
> issuer/business. Issuer creates X money and controls it.
The web page is a bit vague on this point, but if I understand correctly, coins
are created by individuals but issued (?) by a central mint:
"Total circulation will be 21,000,000 coins. It'll be distributed to network
nodes when they make blocks, with the amount cut in half every 4 years."
> In the hashcash idea, the proof-of-work is used to "mint" the coin.
...
> The idea is a sort of poor shot at the "rarity" aspect of money.
No, this is completely incorrect. While the proof-of-work algorithm is used
incidentally for creating coins, the primary use is to securely record
transactions, i.e. the change in ownership of coins. Think of it like a P2P
notary service for digital IOUs (in fact, it can and probably should be
refactored into its own independent network service). The point is not to
create value, but to securely record who owns it. Ideally, is the reliability
of the system is proportional to the computing power of the participants, and
fraudulent use of the system would require more computing power than all of the
honest users combined.
Of course a system that did use computing power as a standard of value would be
ridiculous. If all it took to inflate the money supply was a few CPU cycles,
the value would quickly approach zero. It's only slightly less silly than using
photons as currency. But Bitcoin definitely does not work this way.
My only real complaint with Bitcoin's proof-of-work algorithm is that it's just
busy work, with no other utility except that you can prove you've done it. If
the system's security depends on burning CPU cycles, I'd much rather see it go
to some useful purpose, a la Folding@home or SETI@Home or something. Any
mathematical algorithm would do, so long as it had the properties of:
1. lots of work to calculate,
2. almost no work to verify, and
3. is useful in a real-world application.
Pretty much anything that requires numerical approximation would do: polynomial
roots, numeric integration, eigenvectors, multiple linear equations, etc. A
simple web service could be devised to allow people to submit equations to
solve, notary peers would grab one, compute and publish the results (along with
a block of recorded transactions). Useful math gets done for the scientific
community, while the payment community can be confident that no one's cooking
the books.
> However, for circulation of the credit based upon individuals'
> capacity to provide goods and services, then the Bitcoin approach may
> well stack up, because it simply will not be worth "cracking"
> encryption etc
That's probably the most interesting feature of Bitcoin: it can't be "cracked",
because "cracking" is the proof-of-work itself. Or in other words, everyone is
attempting to crack it all the time, so in order to achieve any benefit, you'd
have to out-crack all the other users combined.
And if even someone could amass enough computing power to insert fraudulent
transactions into the network, it would be self-defeating: it doesn't matter how
many Coins you fraudulently accumulate, if to do so you have to reduce the value
of all Coins to zero.
> As I have said before, the principal attraction to me of Ripple is its
> methodology for settling obligations with obligations. The nature of
> these obligations is immaterial to Ripple.
Absolute agreement. However, the devil is in the details, and I see no hope of
Ripple becoming a viable exchange system until a workable secure distribution
architecture can be devised. I think Bitcoin has the perfect solution for that.
-- Steve
At any rate, controlling lots of cpu power only lets you reverse your
own transactions, which are unlikely to be worth more than the
required cpu power to do so especially given that botnet cpus can be
also spent sending spam, which results in real dollars :) The security
of the network is thus proportional to its size, which is in turn
proportional to the value of the "economy" it represents.