Topic: Bitcoin-like implementation of Ripple - page 2. (Read 13371 times)

Hi JT, F% of the amount of each coin is lost each time its spent.


Their are equal pros and cons in each case. but..


...I hate that equation. Money doesn't have 'velocity' contrary to popular imagination. Most of the time a money token just sits in one location. Very occasionally it moves. At the moment, each dollar of base money moves about every 8 months. Thats not like velocity, like water thru a pipe, its more like electrons tunneling. So more of a stochastic, quantum type event than a flow.

I don't think that equation is that useful in the real world.

Secondly, you say you don't like interest but demurrage per year is not only interest, but it is imposed artifically.

Whereas what I propose, the fee charged when spent is a transaction fee , which I promise you will make more sense to everyday people than a negative nominal interest rate will do.



Its a shame you feel that way. You cannot load political or ideological views on a money system and expect it to succeed. Ripple is a pure system of bilateral agreements and as such there is no business for you or I to impose a particular form on these voluntary bilateral contracts. If two consenting adults would like to charge one another interest, so be it.

OTOH, the transaction fee is perfectly understandable as a fee payable to the community who enable, via the donation of their MIPS, trade to take place.

Speaking for myself rather than for Mike...

Suppose I'm happy to lend money to my friend Fred, but not directly to Fred's friends. With RipplePay, Fred's friend Sue can get the use of my money, though it's Fred who has the ultimate liability to pay me back.

But if Sue disappears and doesn't pay Fred back, it's going to ruin my friendship with Fred when I pressure him to pay me back Sue's loan out of his own pocket. It doesn't help the friendship if I say to Fred "It's your fault because you decided that you trust Sue".

No.  Ripple only has a few non-distributed/single-server implementations that are still really proofs of concept.  We are working on a feasible distributed protocol, as well as designing marketplaces to motivate growth in the network.  I understand there is some interest in using a Ripple-type system for real-time approval of Bitcoin transactions in, for example, a POS setting, which is one of the motivators of renewed work on the protocol.

Ryan

Hi Mike.  I'd like to understand this concern...  If you're comfortable granting credit to a friend (ie, lending to them) on the system, why would you not be comfortable lending them your IOU to give to another one of your friends (ie, vouch for them)?  Obviously, you only have to grant credit to those people you trust to make good on their debts...  What am I missing here?  Thanks for your input.

Ryan

The only difference in what I'm saying is how the bitcoins erode.
Your proposal is

F% of the amount is lost with each transaction
or
F is lost with each transaction

I don't know, but i guess you mean the first
My proposal is:

D% of the amount is lost annually

The fee with each transaction punish the spend and therefore reduces the velocity of circulation. On the other hand, the demurrage stimulates the spend and trade with the currency, because the longer you hold the money the more you lose.
I guess time here can be measured with the block counter.
Here we got the formula we're supposed to be talking about if we want to reach stable prices(http://en.wikipedia.org/wiki/Money_supply#Monetary_exchange_equation):

MV = PQ
M is the total dollars in the nation’s money supply
V is the number of times per year each dollar is spent
P is the average price of all the goods and services sold during the year
Q is the quantity of assets, goods and services sold during the year

Demurrage increases V and make it more predictable.
Demurrage could be adjusted dynamically in function of P, supposing you have a way to measure P.
The typical approach (without demurrage)is to increase M (print money) without knowing anything nor having any control of V. When V is low, crises come.

For me the most important thing for me is suppressing interest, which is the reason I became interested in Ripple in the first place.

That is exactly what I suggested above. Bitcoins are added to the supply each time a block is solved (incentive to contribute CPU resources), but bitcoins erode each time they are transacted with. So, inflation is balanced.

The hard part IMO, is that you don't always want a balanced inflation. When the number of users of the ripple-bitcoin system is growing, you need more bitcoin liquidity. I have never believed in the built in deflation in bitcoin, it seems to me an unnecessary restriction.

So that hard part, is how the bitcoin-ripple money supply is automatically adjusted to grow with the volume of transactions, or equivalently, how a more or less fixed bitcoin velocity is maintained in this system of balanced demurrage and supply inflation.

The benefits over the existing monetary system are greater for ripple than for bitcoin. Bitcoin is way better than national currencies, but is very similar to gold. An economy based on gold have interest which I think is evil:

http://finanzcrash.com/english/aberrations.html

Bitcoin has no way to warranty stable prices. It's deflationary.
Ripple can achieve stable prices:

https://bitcointalksearch.org/topic/m.53145

I think Ripple should target users of LETS.
Botch projects are radical and hard to accept by most people I know. I'm going to sound like a conspiracy theorist, but I think the coming destruction of national currencies (managed by the elitists in order for the world to accept one global currency) will be an opportunity for any alternative: precious metals, barter, LETS, Ripple, bitcoin...
Bitcoin and Ripple are my favorite ones.
Even if the collapse of the inflationary national currencies is not planned, it will eventually come with the coming energy crisis.
Most people can't even conceive peak oil, so explain the need for alternatives currencies is always hard.

Ripple is an interesting concept and I discussed it with Ryan some years ago.

It tries to solve a different set of problems to BitCoin. The biggest issue I have with it, is that the benefits over the existing monetary system are not that big and it's a very complex way to handle debt. In particular the way I become transitively liable for the debts of my friends is something that's difficult to swallow for many people.

The automatic detection and destruction of circular debt was always more interesting to me, but Ripple in general is such a radical change to how money works that it's going to be much harder to get traction than BitCoin - which itself is seen as radical and risky by many folks, even though conceptually it's just another currency.

I don't know. maybe you can ask in the ripple forum.


well you should say why. There is nothing wrong with the fiat system except for its centralization. Having liquid cash that is accepted by all for clearing debts and for performing instant transfers of value for important stuff such as proof-of-work fees without loose ends is advantageous, especially if the way such currency is brought into being is through doing publicly accepted crypto work and the way the currency is retired is also encoded into the system in a decentralized manner.
[/quote]

Ok, you made me change my mind again.
I said that the issued currency could be rejected by some seller, but if the system allows the use of that currency to clear debts, then that currency would be obviously valuable.
You're view reminds me a post I wrote here before knowing the existence of ripple:

https://bitcointalksearch.org/topic/one-network-but-multiple-currencies-2910


To avoid inflation I have another proposal: demurrage.
The bitcoins created can lose value constantly in time so that the amount of bitcoins removed from circulation this way equals the amount created to pay the proof of work.
Obviously, the demurrage would be applied after some quantity of them are circulating (¿21M?).
The demurrage would have another benefits: suppressing interest, stimulating the circulation (that can prevent crises)...
I have posted about it here:

https://bitcointalksearch.org/topic/freicoin-bitcoin-with-demurrage-3816

This sounds like a system in which assets, rather than liabilities, are a circulating medium of exchange. By saying that someone else's IOU must be accepted by others you are inverting the normal construction of any debt based system on its head. That can only work if the original issuer of the IOU IS trusted. Again, it comes back to some notion of reserve currency, which is no more really than saying this nodes debt is the best of all the nodes. In fact it is the same as a fiat currency regime in which IOUs written by the government are to be accepted by everyone els,e and of course there are laws to ensure this is the case.

One  way to deal with that flaw is to have the fees charged up front. The successful computer of the block is rewarded at the instant the block is solved and broadcast with a new coin. Assuming that block makes it into the longest chain then that chain also incorporates the validation of his coin.

Obviously this rubs against the built-in deflation of bitcoin but it is worth examining the economics here. Essentially one can have a node-incentive provided as an IOU redeemed after the fact in which case all transactors (buyers and sellers) give a small part of their purchasing power to the solving node, or you have the same fee charged in the form of inflation to all transactors. Except, not quite because with the latter only holders of debt are charged, not debtors. That can be balanced by having interest fees on outstanding debt, but that would be a matter for individual debtor-creditors to set for themselves.

Lastly, could it be done alternatively such that each time a coin gets used in ANY transaction it has its value decremented. That is, it is clipped and the clipping discarded. Eventually there would be nothing left of it. This would counter the inflationary impact of new coins. It also has the nice side effect that if you don't spend a coin it doesn't lose any value - it just loses value when it circulates. Essentially it has the same outcome as paying fees to the solver, but without all the troublesome  loose ends.


Just to be clear, I am suggesting that there are no IOUs for fees, just new bitcoins in lieu of fees. I am suggesting a hybrid which does away with the 21M coin limit and perhaps uses an eroding coin to balance inflation. If 50 coins are made with a new block, that works fine. After 50 uses the coin will have no value left (effectively, it has all gone in fees).

[quopte]
What you're suggesting, I think, is a hybrid system with money based on debt between trusted parties (ripple's IOUs) and fiat (or electronic commodity backed if you wish) money.
I thought about that too, but finally I decided I don't like it.
[/quote]

well you should say why. There is nothing wrong with the fiat system except for its centralization. Having liquid cash that is accepted by all for clearing debts and for performing instant transfers of value for important stuff such as proof-of-work fees without loose ends is advantageous, especially if the way such currency is brought into being is through doing publicly accepted crypto work and the way the currency is retired is also encoded into the system in a decentralized manner.


Ryan did warn that that might be the case I think!

Does ripple have working point of sale systems?

My proposal was to set the rules for valid transactions so that any user in the network has to accept the IOU's created as fees to the node even if they don't trust the original issuer of the IOU. Once these IOU's belong to a subnetwork that trust the issuer, those IOU's can be treated as normal and be destroyed by coming back to the issuer. The flaw in this is that if the issuer address becomes isolated, then the IOUs against that address are not redeemable and would stay in circulation forever.


If a "master" node misbehaves the other nodes won't accept his block as the next block in the chain, so it's impossible for a node to misbehave.


The IOU's issued here could be denominated in bitcoins. This way it would be easier for the nodes to calculate how much they earn by helping "ripple-coin" compared to what they earn helping bitcoin.
Each new bitcoin block generates 50 new bitcoins and not 1 (anyone correct me if I'm wrong).

What you're suggesting, I think, is a hybrid system with money based on debt between trusted parties (ripple's IOUs) and fiat (or electronic commodity backed if you wish) money.
I thought about that too, but finally I decided I don't like it.

I will post on Ripple forum, but I need some time to answer Ryan's long posts and I've been busy lately.
I'm very glad you are interested in my proposal. What a pity that no one seems to be interested here in the bitcoin community.

Hi, I came here from the ripple forum. I completely agree with your suggestion.


All I have to add at this stage is to help solve this problem:


The situation here is exactly analogous to the way fiat money works. In this case the block chaining node (master node) needs to be compensated, but he does not trust those who would pay him. This is solved by allowing the master node(s) to coin digital currency. He spends this as he sees fit on goods and services from other cell members, and he can do this because the currency is accepted for clearing debts among all those nodes subscribing to the master nodes cell.

The cell members then return this currency to the master node in payment for his cpu effort (and no doubt other efforts he would make in maintaining an active cell in the real world). The nice thing here is that the master node effectively gets paid 'up front' when he creates new currency.

Of course the situation is exactly the same as the US dollar reserve currency. It is created and then some of it is demanded back as tax. Except happily in this ripple/bitcoin case, if the master node misbehaves is is straightforward for the members to leave and create a new cell with new master nodes.

The currency issued here would obviously be bitcoins. If each new ripple block created also created 1 bitcoin as a side effect, then it is all quite neat I think.

I've posted this same message in the ripple-project group:

http://groups.google.com/group/rippleusers/browse_thread/thread/eac0505ca4e5b839?hl=en

I want to convince you of the necessity of merging Ripple and Bitcoin projects. I'd say Ripple is the What and Bitcoin is the How.

For those of you who don't know what LETS is, I'd recommend you to watch "The money fix" documentary. Once you understand LETS, you can say that it's limited to small communities in which everybody knows each other. Ripple solves that problem by turning the community into a network. Ripple is a generalization of LETS. You can build a LETS community inside a Ripple network. In fact, a LETS community's accounting can be transferred easily to a Ripple Server.
 
The problem with Ripple is that the users must trust the server. Not only as a third party, the organization running the server can suffer legal bullying like Liberty Reserve or egold.
Here's where Bitcoin comes in. Bitcoin solves these problems by using proof of work and public key cryptography. Ripple can use these technologies too.
 
For the unit of account, many "currencies" can be used at the same time (like is currently done in Ripple). However, if the users of that unit want stable prices, I think the better approach is to define a currency as a basket of commodities, like Terra Reference Currency. Since ripple doesn't have to store the commodities to back the currency (because is not a currency but a unit), the basket can be composed of any number of different commodities.   

Now I want to start a draft of the design of a ripple-coin software. I've read the bitcoin white paper, but please correct me if I'm wrong in any technical detail.

In bitcoins transactions, the sender signs the address (public key) of the receiver so that everybody can verify the transaction.
On the other hand, a transaction in ripple is composed of several "micro-transactions" between all the agents in the chain of credit.
Let's have an example for the shake of simplicity.
User A wants to pay 10 units to user Z, but they're not directly connected. Let's assume that A is connected to B and B to Z with enough credit so that the transaction is possible according to ripple rules. In order for this transaction to be safe, it has to have the following micro-transactions (each of them signed by the debtor):
-A owes 10 to B
-B owes 10 to Z
Each transaction must obey two simple rules:
   1) Every Agent that appears in the transaction but is not the sender or the receiver must finish the transaction without moving his balance in any direction.
   2) The receiver must increase his balance in the amount that the sender reduces it.
The first problem appears: A needs B to be online when he pays Z, because he needs B to sign that owes money to Z.
If we don't want that painful limitation, A needs another way to proof that he can owe 10 to B, and that B can owe 10 to Z.
Two solutions come to mind.
1) The whole "credit graph" is stored in the block chain. There are pseudo-transactions or credit transactions in the form "A signs B can owe him up to 100 units".
The block chain would be bigger and it would contain a lot of data that doesn't represent any real transaction. Another disadvantage is that all the credits would be completely public.

2) The credit transactions are send between clients (not nodes) and they store them for later use. The problem is:
How can an address cancel (or decrease) the maximum credit it gives to some other address once it signed the "credit transaction"?
The solution a thought is that the credit transactions should contain a block number after which the credit expires.
The clients would have to renew their credit with each other. The clients can send their CT (credit transactions) not only to its neighbors in the Ripple network but to any client in the p2p ripple network.

Once a transaction is in the block chain, all its CT can be used for anyone (always following the rules). If they want to increase the debt for a given CT, they cannot exceed the maximum credit (taking to account every previous uses of that CT) and the transaction reusing the CT must be in a block previous to the Expiration Block Number.
If they want to decrease the debt, the block number doesn't matter and, of course, the debt cannot go under zero.
   
Privacy
To maintain privacy, a Ripple-coin agent can have multiple addresses, just like in bitcoin. The problem here, is that some debts could stay forever in the block chain if the debtor address becomes isolated in the credit graph.
Since the neighbors trust themselves, there are different solutions. Remember you can sign one of your new addresses with the old one to demonstrate to your neighbor that it belongs to you too.
1) The creditor cancels the debt in a transaction and the debtor creates it again (between different addresses) in another transactions.
2) The creditor accepts debts from the debtor's new address. The debtor's new address pays to the old address through the creditor so the debt is now in he new address and the old address debts are equal to zero. 
There has more ways to get the same result. We want them the less traceable and the more automatic possible.
In the other hand, some agents can give up privacy to be more "trustable". They can, for example sign with their address documents describing them or their organization.

Incentive for the nodes
As an incentive for the nodes, in bitcoin they can create a new bitcoin if they're able to supply the next block. In the future there will be no more new bitcoins and the incentive will be the fees charged by the nodes. As ripple-coin cannot create debt from nobody to the nodes, the transaction fee seems the only way to encourage the nodes to "waste" their CPU power. The problem with the fees is that the payer in a transaction has to be trusted (directly or indirectly) by the node. The fee can be charged to the receiver of the transaction instead of the payer. The receiver seems more "trustable" since someone (at least the payer) owes money to him. But the nodes still have to trust some unknown agent. The nodes could still refuse to record transactions if they don't trust any of the two main agents in the transaction. The only solution that comes to mind is changing the rules so that the money owed to the nodes in concept of fees must be accepted by anyone until it is "destroyed". That happens when the original debt is owed to someone who trusts (directly or indirectly) the original debtor. The original debtor (of the fee) can become isolated in the credit network, so the solution is not flawless.
 
Any criticism to this design from both communities (Ripple and bitcoin) is welcome, as well as fixes and different technical approaches.
I will defend the analysis the best I can. That is a Ripple-like system implemented in a p2p fashion that is secure and keeps acceptable levels of privacy.   

English is not my first language so I'm sorry if a repeat some words too much or if some sentences are not grammatically correct.