For those who are interested but don't know how Bitcoin works exactly,
there is a lot of good information here:
https://en.bitcoin.it/wiki/Category:Technical
As I understand it, what you're suggesting is that each Ripple client
hold a snapshot of the entire network state as it was when the last
block was generated, plus all the transactions since then, and how
they affected the state of the network. To perform a transaction, a
client would simply compute the route itself using its version of the
network state, and then broadcast that information out to all the
other clients in the network. To update the credit limits it sets for
its partners, a client would just broadcast that as well.
Conflicts get resolved over time in the brilliant Bitcoin way: the
block chain. For those unfamiliar with Bitcoin (and correct me if I'm
wrong), the way transactions get validated and accepted by the network
at large is by some peer finding a special number such that if you
concatenate it with all the transactions since the last block, and
take the SHA-256 hash of that value, you get a result below an
agreed-upon target value. This is difficult to do. If a client
trying to compute the next block receives two conflicting transactions
(ie, double-spending) for inclusion in the same block, it can only
include one in its computation, or the block won't be accepted as
valid when its is broadcast out.
Eventually someone computes a next block (in Bitcoin, the average is
somewhere around 10 minutes), broadcasts it out, and anyone who made a
transaction in that block can start to feel more comfortable that
there were no conflicts with their transaction. However, it's
possible (though unlikely) that someone else computes a competing, but
also valid, block with a different set of transactions starting from
the previous block. In this case, clients who want to compute the
next block can choose to work from either candidate block to try to
grow a longer chain of new blocks on top of the one they like. The
fundamental principle that clients have to agree on for a unified
network to work is that the longest chain, representing the biggest
pool of computing power, becomes the agreed upon transaction record.
Now, even though conflicting transactions in Ripple are much more
likely than in Bitcoin because transactions involve commandeering
other people's credit, I believe this mechanism would work perfectly
well for resolving conflicts, at the cost of real-time clearing. You
would have to wait an hour or two to be certain your Ripple
transaction cleared. In fact, some people were talking about
implementing Ripple for real-time Bitcoin transactions:
http://www.bitcoin.org/smf/index.php?topic=2628.msg36/ripple809#msg36809
And actually, as a seller, if you have a recent snapshot of the
network state, your software can make a good guess at the probability
of a transaction clearing, assuming the payer isn't purposely trying
to defraud you by double-spending the same credit at the same time. I
think that's good enough to start with, and we could layer on
additional safeguards later.
I like that it avoids difficult issues with the real-time distributed
protocol design, such as routing scalability and lack of atomicity of
transactions.
The main issue I see, however, is the same as for Bitcoin: every
client must receive, compute the validity of, and store every
transaction (all the way back to the beginning, if you don't want to
trust any other server), which will pose obvious scalability issues.
Bitcoin has been operating for a couple years, and right now there are
around 6000 Bitcoin clients online at any given time
(http://www.bitcoin.org/smf/index.php?topic=3149.msg44294#msg44294),
and my client stores 158 MB of transaction data.
If we want a network capable of handling millions of users and all
their transactions and credit limit updates (we haven't even talked
about exchange rates or other features), the bandwidth and CPU
required to fully participate in the network is going to be enormous.
To cope with this, I would imagine most users would prefer a
client/server arrangement, where servers were the actual Ripple peers,
and clients accessed and directed them using web and other interfaces,
rather than storing the entire history of the network in their phone.
I believe most Bitcoin users will move in the same direction
eventually too.
It will be years before the network faces this scalability issue, and
bandwidth and CPU speeds might keep improving such that it is not an
issue. My instinct says that we can't just rely on hardware
improvements to make up for bad design though.
There also might be ways to divide up the network into cells so each
cell manages its own block chain and internal transactions, and
abstracts those away to the other cells, so the global block chain and
transaction set was much smaller. This could be good for privacy too.
Unfortunately, it involves putting a hierarchical structure onto an
fundamentally non-hierarchical network.
On the privacy issue, I'm also not as concerned about that as I used
to be. People can run private Ripple networks and interface with the
global network through proxies and such.
I have to run, but I'll definitely be thinking more about this. I
think there's potential.
Ryan
> --
> You received this message because you are subscribed to the Google Groups "Ripple Project" group.
> To post to this group, send email to rippl...@googlegroups.com.
> To unsubscribe from this group, send email to rippleusers...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/rippleusers?hl=en.
>
>
I think this will be OK. You don't have to trust someone to accept an
IOU from him/her. You can gauge its value by looking at the network
over time and estimating the chances that he/she will disappear or cut
the connections that make that IOU valuable. As a client trying to
compute the next block, you could see the IOUs promised to you if you
succeed, and then decide how much that is worth to you. Since it
really isn't any more work to include more transactions in a block,
you might as well accept all IOUs and use them however you can. You
might even be able to convert a few of them into trusted IOUs using
circular transactions.
> 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.
I would say that either or both of the payer or recipient could pledge
fees for processing, but that each could only pledge on his/her own
behalf.
Ryan
* Bitcoin broadcasts every transaction to every client. If Ripple did
this, it would mean greater bandwidth usage, less privacy, but much
easier routing, since every peer has enough information to compute
routes on its own.
* Bitcoin transactions are validated by the block chain. If Ripple
did this, it would mean no real-time transaction approval, but it
would allow peers to go offline without disrupting the network, and
also that transactions could be atomic -- no transaction could get
stuck half-committed, which is possible, though unlikely, in the
current design (see below).
I don't think that needing to trust a server is really an issue,
because you can always run your own server (your own peer on the
network). If and when Bitcoin becomes a much larger network, you will
need much more hardware to run a full peer, though, and the wiki
posits that peers will be rack servers:
https://en.bitcoin.it/wiki/Scalability
In Ripple, the advantage to running a peer on a server rather than on
a regular home machine, laptop, phone, etc. is the always-on
requirement of the real-time version. I also believe that most people
are not properly equipped to maintain authoritative copies of their
own financial data, since they cannot be relied upon to keep backups,
in which case a server is a better arrangement. Also, when the
network gets large, the bandwidth and perhaps CPU requirements may
surpass what is available to most consumer machines.
Anyways, I am thinking about a hybrid between the Bitcoin model and
the Ripple real-time model:
* I like the idea of every node having enough information to compute
routes on its own. That means that a relatively accurate available
credit for each direction of account should be broadcast soon after
any balance or credit limit change. Available credit limit changes
could be broken up into deceivingly-sized and -timed increments to
make it difficult to reconstruct any transactions from them. There is
no need for a block chain to validate this information just for
routing purposes -- each address can sign its own balance change
messages to authenticate them. Now any peer can generate one or more
decent candidate routes for its transaction and make attempts to use
them without launching on a big distributed fishing expedition for
available credit.
* Transactions would be processed following the real-time model. The
main issue with that model is when there is a real or feigned
connectivity problem between two intermediaries, and the commit
message doesn't make it back to the payer before the transaction
expires. It is then up to the two intermediaries to sort out who was
responsible for the outage, and who will get stuck with the loss.
Agreeing ahead of time on a trusted third party to time-stamp and
attempt to forward these frustrated commit messages, and then referee
any further dispute based on its observations of the two
intermediaries' hosts' behaviour is one solution to the issue. But a
better solution might be for the payment recipient or any other
intermediary to broadcast the commit message (which doesn't identify
any of the parties, and only the recipient can create) for inclusion
in a global block chain of such messages, where every intermediary can
see and agree that it was exists and was generated in a certain time
frame, and therefore must live up to its promise.
The goal here isn't to replace the real-time processing of the commit
message back down the transaction route, it is just to moot any
attempted shenanigans as well as to resolve any disputes about whether
a particular transaction promise between two intermediaries must be
fulfilled or not. To that end, promises should be set to expire, not
at a certain time, but after a certain number of blocks have passed.
So any intermediary thinking about trying to gain from deceitfully
refusing a commit message would have odds of success equal to the odds
of the commit message being left out of the next N blocks -- pretty
tiny odds, I think. Therefore the commit message should be passed
along in a timely manner back to the payer, who can then present it to
the recipient as proof of payment and collect her goods. And if an
intermediary happened to go offline honestly for the duration of the
transaction, the payer would receive the commit message broadcast over
the whole network regardless.
An attack on this would be for the payer to control all the peers
connected to the recipient and every intermediary, so no one can
broadcast the commit message and it never gets into the block chain,
but yet the payer gets it and uses it as proof of purchase to collect
good from the recipient. Bitcoin already has some strategies to try
to avoid anyone being able to monopolize anyone's connections, and
monopolizing multiple peers' broadcast connections seems like it would
be very difficult, especially if peers broadcast to all their
connections' servers.
Any comments on the broadcast of available credit for routing
purposes, or use of a block chain to improve atomicity of
transactions?
Ryan
This could be made quite scalable I think: Every peer doesn't need to
know about the available credit on every account in the whole network.
A peer could just listen to the broadcasts and pick out the accounts
it considers useful to know about (nearby accounts and others it
thinks it might use for payments) for caching and rebroadcast. If it
needs to learn about an account it doesn't know, it can broadcast a
request for it. If it also broadcasts the amount it wishes to send to
that account, it might event receive back a custom-made path. The
incentive for fulfilling such request could be just that you get to
decide where someone else's transaction goes, which might be
favourable to you.
Also, the payer chooses a candidate path for the transaction and sends
it out when it initiates the transaction, but if that path does not
have enough available credit for some reason, the intermediary at the
blockage should be able to try another route, which may very well be
more successful, since it is closer to the recipient, and likely have
more up-to-date information on available credit in that region of the
network. Of course, intermediaries could just choose different routes
based on their preference, which I think is fine, as long as those
routes ultimately meet the payer's approval.
Ryan
http://ripple-project.org/Protocol/Index
I won't deluge this list with my new thoughts. If you're interested,
please read the wiki. In brief, the new (ish) discussions are:
Building Cells By Block Chain - Improve privacy and scalability by
letting well-connected groups of peer endpoints self-organize into
cells whose internal connections are then abstracted away from the
greater network.
http://ripple-project.org/Protocol/BuildingCellsByBlockChain
Tunneling - Improve anonymity and privacy with secure communication
tunnels to other endpoints.
http://ripple-project.org/Protocol/Tunneling
Proxies - Proxy transactions through other endpoints, obscuring the
true source or destination of transactions.
http://ripple-project.org/Protocol/Proxies
Happy to hear comments.
Ryan
Ryan
If they are computing blocks, they already have excess computing power
available, and have enough bandwidth to continuously collect all
broadcast transactions, so this isn't a concern. Furthermore, they
don't *need* to compute the value of IOUs offered for computing the
next block if they don't want to -- they can just take what they get,
and estimate the effort they should dedicate to block computations by
averaging the value they actually redeem from those IOUs over time.
Sure, knowing what value you'll get from the IOUs in any given block
is a crapshoot, but then again, computing a block is a crapshoot to
start with.
Ryan
Definitely, the price of computing the next block needs to be high enough.
> My proposal about having block solvers issue coins was a practical response
> to the problem of having IOUs which people are forced/committed to accepting
> regardless. An IOU which people are forced to accept is equivalent to
> outside money
>
> http://en.wikipedia.org/wiki/Outside_money
>
> An IOU which people are forced to accept is not by definition an IOU, it is
> more akin to a tax of some kind.
You're right. Forcing the network to accept certain IOUs is like a tax
and I don't like that. Furthermore, a transaction recorded as valid by
the network doesn't have to be considered valid by the receiver. He
can turn the transaction back and don't deliver the good/services.
An issued currency can be rejected by the agents too (it doesn't
matter if the network accept the currency in transactions), so both
proposals have the same flaw.
A node can compute the "redeemability" of the fee for a given
transaction and then decide if he includes that transaction in the
block or not. What you're saying is that the calculation of the next
block would be equally hard if you include a given transaction than if
you don't and therefore there's no incentive for the nodes for not
including a transaction even if the node estimates that the
probability of redeem the fee for that transaction is very low.
In bitcoin you can configure you're client and set the maximum fee
you're willing to pay. I think you sign it in the transaction before
broadcasting it to the nodes. A node that charges a greater fees than
the your maximum won't include it the block (but hopefully another
cheaper Node will do it).
Imagine a node charges a fee of 0.15 BTC. Including in the block a
transaction that would pay him just 0.05 BTC doesn't have additional
costs, so the node doesn't have an incentive not to include the 0.05
fee transaction. What would happen here?
Maybe we need to ask in the Bitcoin forum for this one...
In our system, if not all fees are redeemable, the income for
generating a block becomes harder to calculate and so the income for
running a node.
An investor needs to calculate this income before deciding to run a
node. That income has to be equivalent (or bigger) to the income of a
Bitcoin node or very few people would run our nodes and everybody
would prefer to run a Bitcoin one.
Sure. I read in the Bitcoin forum, and it seems to me that his
solution is to integrate a Bitcoin-style electronic commodity currency
into Ripple and use that for paying transaction fees. "Ripplecoins"
would get created when someone solved a block. Since most every node
needs to pay transaction fees, this currency would be acceptable to
most as payment for other things too, like clearing debt.
This is not a bad idea, I think, and is proven to work already by
bitcoin itself. If there's going to be block chains in the protocol
already, then adding digital coins and their transactions to that
block chain doesn't impose much extra in terms of implementation
effort. (Bitcoin's full scripting capability for specifying custom
conditions that need to be satisfied before transferred coins can be
spent doesn't seem necessary.) And it does seem fitting to reward
those computing blocks with a greater ability to ensure that their own
commit messages get included in future blocks.
The main drawback, I think, is that nodes that have no Ripplecoins are
vulnerable to their commit messages not being included in the block
chain. The obvious answer to that is that those nodes should try to
earn some Ripplecoins, or buy some from their friends using Ripple
IOUs.
So I agree that this is a better idea than having nodes promise IOUs
to the client that computes the next block.
Then there's the question of inflation. I'm not sure this is a major
issue. Suppose that one Ripplecoin gets minted every block, and the
supply of Ripplecoins keeps growing indefinitely. If the value of
having a block's commit messages included in the block chain remains
constant, then the fee for having this done should increase. This
doesn't bother me, since (1) the network should be growing for a long
time, and along with it the value of having a block computed, and so
increasing the supply of Ripplecoins for this purpose makes sense; and
(2) the Ripplecoin supply only grows linearly over time, not
exponentially, so inflation approaches 0% -- in other words, once the
Ripplecoin supply is large, and the network is at steady-state, one
extra Ripplecoin per block isn't going to significantly affect the
value of Ripplecoins.
Thinking about it, I'm actually surprised Bitcoin doesn't do it this
way. In the end, though, I don't think the inflation question is
terribly important. However the value of Ripplecoins changes over
time, they should still be able to perform their function of
encouraging a sufficiently large pool of computational power to
participate in computing the block chain, making it very difficult for
nodes to profit from misbehaving in the process of committing Ripple
transactions, which could make the network unreliable.
Ryan
> We've been discussing this issue in the bitcoin forum too:
>
> http://www.bitcoin.org/smf/index.php?topic=3557.msg52482#msg52482
>
> I'm very interested in knowing your thoughts on my solution to the
> "always online problem".
> Your solution implies that the user have to give its private keys to
> the representative node in order for him to sign the transactions.
> Mine, (just to remember it to you) is "pre-signed" credit permissions
> (or credit blocks) with an expiration block-number being sent between
> the clients.
> The debt Graph would be in the block chain (and in the nodes) while
> the Credit graph would be in the clients. No one can be sure that it
> has the whole credit graph and the clients could have different
> privacy policies for how and who to send the Credit blocks/
> permissions.
>
In my real-time version, only commit messages go in the block chain.
No one knows the debt graph. The credit graph is broadcast, but only
as a guide to routing, not as authoritative promises of credit
availability. Transactions are approved in real time by the nodes
involved. But the discussion of how to motivate computing the next
block applies regardless.
Ryan
The solution of Daniel does not involve fees to the Nodes. The nodes get the created money.
The fee he talks about is payed to no one. The ripple-coins are diminished with each transaction in order to avoid inflation.
The way he makes them valuable is by forcing them to be accepted to settle ripple debts.
I prefer demurrage as the better way to avoid inflation.
No. Your force them to be accepted for making transactions. A ripple debt can quite happily be settled in dollars. The community is bound to accept the inflation of the coin supply as a result of payments to community MIPS resources being used to benefit the community. The forcing is not active, like forced IOUs, its passive via inflation.
OK. Let me see if I understand the reasoning: The goal is to
motivate participation in computing the block chain by many
independent parties, so that the network is difficult to game for the
benefit of the few.
Whoever computes a block gets some Ripplecoins. Those Ripplecoins
have value because some participants derive value from having a strong
block chain keeping the network reliable (lots of compute resources
devoted to block chain = hard to attack). These participants will
accept Ripplecoins in payment to the extent they desire a strong block
chain.
My problem with this setup is it enables free riders to benefit from
the work of the few. Even if I value a strong block chain, I can
gamble that others will take care of it for me by refusing to compute
blocks or accept Ripplecoins. (No one can compel me to accept
Ripplecoins.) The clients who do the work of maintaining the system
will not receive full value for the work they do. This is a classic
tragedy of the commons scenario and it is a negative feedback loop
that weakens the network.
If you enable nodes to give Ripplecoins to whomever computes the block
containing their commit message, there is a more powerful incentive
for everyone to actively participate in keeping the block chain
strong, by working on computing blocks, or by accepting Ripplecoins:
If everyone always includes every commit message they see in the next
block they are computing, then there is no need to include Ripplecoins
as a processing fee with your commit message, and the demand for and
value of Ripplecoins decreases. If it gets to the point that
insufficient computing resources are going into the chain, and
participants who care and are computing blocks begin to feel that the
network is susceptible to attack, they can start randomly excluding
some messages from the current block, with smaller-fee messages having
a greater chance of being excluded. That will motivate nodes who want
their messages included in the block chain to obtain more Ripplecoins,
driving up their value, and motivating more participation in block
computation.
With fees, the block chain becomes a functioning market where those
with computing resources sell those resources to those that benefit
from it, and receive full value. No free riders.
> The fee he talks about is payed to no one. The ripple-coins are diminished
> with each transaction in order to avoid inflation.
With processing fees, I'm not sure how important it is to avoid
inflation. Getting the Ripplecoins for computing a new block will
pale as a motivator beside receiving the processing fees, which can be
adapted to any inflation. The important thing is that the value of
Ripplecoins is predictable enough over time that the market for
including commit messages in blocks can function.
On Thu, Feb 24, 2011 at 12:16 PM, danny jp <dann...@gmail.com> wrote:
>>
>> The way he makes them valuable is by forcing them to be accepted to settle
>> ripple debts.
>
I'm not sure this quite works either. As a seller, I might try to
gain an advantage over other sellers by not requiring a Ripplecoin for
transactions, gambling that enough other sellers will to keep the
network functioning properly. Free rider problem again. The best
solution is to have a fee directly for the scarce resource in
question: CPU power. Other solutions are open to gaming.
Ryan
If I got it right, this is how you'd solve the incentive problem:
1) Danny
-ripplecoins are created for the generator of the block
-Constant fees are payed with each transaction (doesn't matter if the
transactions is in Ripple IOU's transactions or ripplecoins) and these
fees are destroyed.
2) Ryan
-ripplecoins are created for the generator of the block
-The fees are charged by the generating nodes in a free market fashion.
The problem with Ryan's proposal is built-in inflation.
The way Danny describes the fees seems very artificial to me.
If fees are going to be charged, I prefer having a free market. That
also allows some payments to be charged with smaller fees (or none),
having to wait more to be included in the next block and therefore
being confirmed (for example, if you're making a donation, you're not
usually very hurry).
We could use an hybrid of the two:
The generating nodes collect fees, but a percentage of the fee is not
received by the generating node and is destroyed.
This way we have a market for the fees and a mean for decreasing the
money supply.
Ryan, if you're not concerned about inflation, maybe the system should
be just like bitcoin (issue a limited amount of time through the first
years), but with support for ripple transactions. I wrote a post with
this same thing (but with LETS instead of ripple, because I didn't
knew Ripple yet):
http://www.bitcoin.org/smf/index.php?topic=2910
One last thing. Forcing the clients to accept ripplecoins to settle
ripple debts would make them more valuable. What's the problem with
that?
2011/2/25, Ryan Fugger <a...@ryanfugger.com>:
I don't really detest interest. What you're saying is that demurrage,
although negative is still interest. I don't have any problem with
interest that are related with cost. For example, interest charged to
cover risk cost. What I think is bad is the "liquidity premium" or
"time value of money". That's I think, a built-in quality of money as
it is, but not as it should be.
Anyway, since no one seems to be interest in demurrage or Gesell's
theories, maybe we shouldn't waste more time in this issue. I strongly
recommend you to read "The natural economic order" although I can't
agree with everything Gesell says.
There's no point in trying to explain you these theories he did that,
and probably much better than I can. Magrit kenedy share these
theories, but I haven't read her book.
If I got it right, this is how you'd solve the incentive problem:
1) Danny
-ripplecoins are created for the generator of the block
-Constant fees are payed with each transaction (doesn't matter if the
transactions is in Ripple IOU's transactions or ripplecoins) and these
fees are destroyed.
2) Ryan
-ripplecoins are created for the generator of the block
-The fees are charged by the generating nodes in a free market fashion.
The problem with Ryan's proposal is built-in inflation.
The way Danny describes the fees seems very artificial to me.
If fees are going to be charged, I prefer having a free market.
http://ripple-project.org/Protocol/CommitBlockChain
Please understand this context for the discussion. It is a far more
minor issue in Ripple than in Bitcoin. Ripple can function without a
block chain. It's just an elegant solution to how to resolve any
conflicts that might arise. There are other solutions that should be
used if a block chain comes with too many complexities.
I would actually imagine the first implementation wouldn't include the
block chain, since it is not important in a relatively low-value,
generally cooperating network.
2011/2/25 Jorge Timón <timon....@gmail.com>:
> The problem with Ryan's proposal is built-in inflation.
My proposal is for growth in the money supply, but I doubt it will
cause rising nominal prices. The growth of the Ripplecoin supply will
be linear over time, but if the network's any good, its growth should
be exponential, at least for a time, meaning price *deflation*, since
Ripplecoin supply will not keep pace with demand during the growth
phase. This will motivate more CPU resources to work at computing the
block chain in order to earn Ripplecoins whose value is increasing.
The new Ripplecoins generated in each block will work counter to price
deflation in two ways:
1. Growth in Ripplecoin supply will tend to drive down their value.
2. More importantly, the increasing value of free Ripplecoins in each
block will make receiving processing fees less important for
motivating block computation, meaning the demand for Ripplecoins goes
down, and so does their value.
If the network ever gets to zero growth, it should hopefully be far,
far in the future, at which point the addition of a small constant
amount of Ripplecoins to the already-substantial supply makes very
little difference to prices -- like I said before, supply inflation
tends to 0% over time.
(If zero growth happens before there is a substantial supply of
Ripplecoins, then the work of computing the block chain shouldn't be
too hard, and the diehards that do it are probably idealists who would
do it for free anyway. So the whole need for Ripplecoins is pretty
moot, and the system might as well just ignore them. Adding more
coins of zero value can't cause price inflation.)
Overall, it actually should be fairly self-regulating.
> Ryan, if you're not concerned about inflation, maybe the system should
> be just like bitcoin (issue a limited amount of time through the first
> years), but with support for ripple transactions.
In the long run, a linearly growing supply is no asymptotically no
different than a fixed supply anyways in terms of how it will affect
participant behaviour. The reason I don't like it is because you have
to arbitrarily choose a time when the rate of generation should slow
or stop, and fees should become more important. If you don't make
this choice, the network will make it on its own, naturally, which I
find far preferable.
If the network is growing exponentially, it should be driving up the
value of Ripplecoins, driving block computation efforts without much
need for processing fees, which makes the network more attractive to
use, driving more growth. I wouldn't want to diminish that effect
arbitrarily if I didn't have to.
> One last thing. Forcing the clients to accept ripplecoins to settle
> ripple debts would make them more valuable. What's the problem with
> that?
>
How do you propose to force clients to accept Ripplecoins to settle
Ripple debts? There is no authority to enforce legal tender laws
here. At best, all we can have is convention, in which case we have
to carefully consider the incentives. It's the incentive to collect
Ripplecoins that makes them valuable, and that incentive is the need
to use them to get your commit message included in the block chain.
Ryan
For a good primer on the context of this issue, and the distributed
protocol design in general, read:
http://ripple-project.org/Protocol/DesignConsiderations
especially up to and including the "Disputes" section.
Ryan
The value of the block chain is to prevent some
very specific types of attacks on the transaction process, as well as
to resolve accidental long-lasting outages during transactions:
Ripple can function without a
block chain. It's just an elegant solution to how to resolve any
conflicts that might arise.
I would actually imagine the first implementation wouldn't include the
block chain, since it is not important in a relatively low-value,
generally cooperating network.
My proposal is for growth in the money supply, but I doubt it will
cause rising nominal prices.
The growth of the Ripplecoin supply will
be linear over time, but if the network's any good, its growth should
be exponential, at least for a time, meaning price *deflation*, since
Ripplecoin supply will not keep pace with demand during the growth
phase. This will motivate more CPU resources to work at computing the
block chain in order to earn Ripplecoins whose value is increasing.
1. Growth in Ripplecoin supply will tend to drive down their value.
2. More importantly, the increasing value of free Ripplecoins in each
block will make receiving processing fees less important for
motivating block computation, meaning the demand for Ripplecoins goes
down, and so does their value.
If the network ever gets to zero growth, it should hopefully be far,
far in the future, at which point the addition of a small constant
amount of Ripplecoins to the already-substantial supply makes very
little difference to prices -- like I said before, supply inflation
tends to 0% over time.
(If zero growth happens before there is a substantial supply of
Ripplecoins, then the work of computing the block chain shouldn't be
too hard, and the diehards that do it
No, cells have nothing to do with requiring nodes to be online. The
requirement for being online comes from wanting transactions to be
approved and committed in real time, rather than having to wait until
it is confirmed by several blocks in the chain.
Cells is an enhancement to the routing mechanism that allows greater
privacy and scalability.
> For price stability (in Ripple, not for ripplecoins) I propose a currency
> which price is calculated like if it was backed by a basket of commodities.
This is outside the scope of the protocol. Users will choose whatever
account units they want.
> There's no limitation to the number of commodities since the currency it's
> not really acked by anything. This is inspired by Terra Reference Currency.
>
TRC is a good unit, IMO.
On Sun, Feb 27, 2011 at 7:31 AM, danny jp <dann...@gmail.com> wrote:
> Nice Summary. Before discussing any further though, we need to settle this
> troublesome issue of price stability.
I'm comfortable with my existing solution.
> The only price stability I believe is
> necessary (or even possible) is that stability which continues to
> incentivise a large percentage of participating nodes to calculate blocks,
> and all nodes to participate in commit transactions, but to keep the block
> calculation premium below the level at which a CPU arms race is begun. Can
> we agree that this is what we are talking about?
No, the CPU arms race is very desirable and precisely what makes the
block chain resilient to attack. As in Bitcoin, the CPU energy
dedicated to block computation will tend towards the value of
generating each block, which will tend towards the value transaction
participants get in having commit messages included in each block. So
there is a limit to how much CPU will be logically dedicated to the
block chain.
> As we discussed before there are two kinds of fees, the fees for block
> calculation and the fees for participating in a commit transaction.
> Intermediaries can be assumed to require compensation for performing
> intermediation, since there is the risk of becoming stuck with a liability.
> In the case of block computation, the fee paid (via inflation or demurrage
> or whatever) is effectively a per transaction fee and is independent of
> transaction value. In the case of intermediation fees, the fee is based on
> transaction value.
> So before continuing with the coin inflation/deflation issue relating to
> block chain compensation, can we establish what the nature of these
> intermediary fees might be - how they are specified and applied and what the
> technical and 'monetary' issues are with them, because I have a feeling the
> form they take would likely influence thinking about the payments for block
> computation, and beyond that, the actual value of a distributed
> server-less architecture over the original server based concept.
I envision transaction fees being charged by each node setting
exchange rates between their accounts. So they are naturally
collected in Ripple IOUs, not Ripplecoins.
I was thinking today that it would probably be good for intermediaries
to charge a very small fee on the act of simply reserving credit for a
transaction, regardless of whether it gets committed. These fees
would also be Ripple IOUs, and would all be passed back to the payer.
The reason is so the network is not so vulnerable to DOS attacks where
transactions get initiated but never completed, tying up credit and
making it unusable until the transaction expires.
I like keeping the only explicit function of Ripplecoins in the
network being paying block processing fees, since that keeps the
reasoning simpler, and also makes for a more modular design.
Ryan
No, the CPU arms race is very desirable and precisely what makes the
block chain resilient to attack. As in Bitcoin, the CPU energy
dedicated to block computation will tend towards the value of
generating each block, which will tend towards the value transaction
participants get in having commit messages included in each block. So
there is a limit to how much CPU will be logically dedicated to the
block chain.
I envision transaction fees being charged by each node setting
exchange rates between their accounts. So they are naturally
collected in Ripple IOUs, not Ripplecoins.
I was thinking today that it would probably be good for intermediaries
to charge a very small fee on the act of simply reserving credit for a
transaction, regardless of whether it gets committed. These fees
would also be Ripple IOUs, and would all be passed back to the payer.
The reason is so the network is not so vulnerable to DOS attacks where
transactions get initiated but never completed, tying up credit and
making it unusable until the transaction expires.
If there generally isn't enough reward for computing blocks, then
those computing blocks will demand higher fees. It should be
self-balancing. It makes no difference if there are 10,000
Ripplecoins in circulation, and fees are around 1 Ripplecoin, or if
there are a million Ripplecoins, and fees are 100.
> Your wiki link says that payment recipients broadcast commit messages with
> arbitrary fees attached, but I'm not clear why low (minimum) fees would act
> to discourage inclusion, since inclusion is free to the solver.
If the network is to be sustainable, there will need to be an ethic of
participation in the network, so that block solvers and those that
support them (by accepting Ripplecoins as payment) will collaborate to
validate each other's transactions, and exclude those free riders that
attempt to benefit from the consensus provided by the block chain
without contributing to its computation. If network participants
agree, then they will run software that favours those commit messages
accompanied by a certain minimum fee.
You make a good point though, that some block solvers might get greedy
and include every commit message that has a fee attached, regardless
of how large. If few nodes are attaching fees below the minimum to
start with, though, there's not much to be gained from this. Also,
the IDs of the Ripplecoins gained from this practice are public
knowledge, so other hosts can blacklist those coins if they wish to
punish defectors from the minimum-fee system. That seems harsh to me,
but I mention it to show that the ethic of participation can be
collectively enforced if there's a will and a need to.
> For there to be no commit-message-inclusion inflation problem, there would
> need to be some way for solvers to increase their fees in line with
> inflation (which as yuo point out would only be an issue if the network
> grows more slowly than the blockchain.
>
Definitely. How solvers might do this collectively is hard to say,
because if it's left to individuals, the first to raise their fee
requirements would suffer losses. But I think that a community order
will evolve where leaders publish fee requirements and others will
look to them. I think there will be a sense of what a Ripple
transaction *should* cost to validate -- say, 1 cent -- and the
Ripplecoin requirements will stay level with that, taking into account
the Ripplecoin to dollar exchange rate.
> Is it possible then for a payer to determine what his overall fee is going
> to be before deciding to commit? This certainty is vital IMO.
Yes. Definitely vital.
> Also, it is going to be very difficult in practice for individual nodes to
> work out how to set their exchange rates to get the right balance. Some of
> their connections may be very active in routing payments through this node
> and others less so.
It may or may not be difficult for nodes to set their exchange rates.
I imagine adding an extra percentage fee for accepting IOUs, and no
fee (or maybe even a negative fee) for clearing those IOUs. This
doesn't affect the design of the protocol, however.
> If all nodes are left to solve the complex problem of intermediary fee
> setting I think the network might choke right from day one. It also results
> in a lot more info to be included in the block chain
>
Exchange rates don't go in the block chain.
The problem of setting intermediary fees is more an issue in for the
client software to deal with that the protocol server software.
Intelligent defaults will go a long way towards making the system easy
to use.
> Lots of very small IOOs and fees are going to clog up the block chain are
> they not?
IOUs don't go in the block chain. Only commit messages do. The
commit message is just the transaction ID signed by the payer and
recipient (or their one-time keys for that transaction), which all the
intermediaries have agreed will trigger their promises to pay forward
IOUs for the transaction.
So the actual details of the transaction don't go in the public record
of the block chain, just the cryptographically authenticated commit
message that all intermediaries have agreed will trigger the
transaction to come into effect. It has no meaning to anyone not
participating in the transaction. Read:
http://ripple-project.org/Protocol/DesignConsiderations
http://ripple-project.org/Protocol/Payment
for more info. In the last document (v0.4 protocol) the commit
message is called a "receipt".
Ryan
If enough processors implement something like this, it gives nodes a
way to ensure that very important transaction commits are included
right away, by including a fee safely above the average. It would
also allows for micropayments, where any significant fee would be
uneconomical, to get in with high probability, but only after several
blocks, meaning they would want to have credit reserved for long
enough that if the payer or an intermediary was trying to not live up
to its promise by ignoring the commit message, it would have a very
small likelihood of succeeding (and would only be able to profit by
the amount of the transaction). Similarly for low-priority payments,
although the tradeoff would be any fee for reserving credit, which
might be proportional to the amount of credit reserved, and the time
it is reserved for.
Ryan
PS: Sorry I don't have time to answer all the questions people have
about how the protocol would work. A lot of it is explained in the
wiki if you read carefully.
If no-fee messages can get included with high probability over a few
blocks, then probably few would pay any fees. So it might make sense
for block solvers to require *some* fee, however minimal. If they're
keeping a moving fee average, they could include messages with
probability (fee / average), which still lets low-value transactions
chip in a tiny fee to get their messages included eventually. They
will be pinched by the cost of reserving credit, which will go up as
the network gets more busy, effectively putting a lower bound on the
value of transactions that can be reliably processed by the network.
That's probably OK.
Danny, you're right though, the block chain/Ripplecoin solution is
quite complex to reason about. The problem we're trying to solve is
essentially this: A payer makes a payment to another node he
controls, through a bunch of other nodes. He promises to pass IOUs
forward if the commit message comes before a certain time, but then
when it does come, he pretends he is offline until his promise
expires, meaning he has received value at his recipient node, but has
not passed any value forward from his payer node -- he has stolen
value.
To solve this, an intermediary node must be able to prove they were in
possession of the commit message and made a good faith attempt to give
it to their predecessor in the payment path before the transaction
expired. If they can do this, the predecessor must make good on his
promise to pass forward value. If not, the predecessor is off the
hook.
Now, if the value of CPU time dedicated to computing the next N blocks
(ie, the estimated value of Ripplecoins received for computing the
next N blocks) is significantly less than the value of the circular
payments that an evil participant can make through some intermediaries
between his own nodes with a promise expiry time of N blocks, then
that evil node could potentially profit by paying for a large amount
of CPU resources to compute the next N blocks with high probability,
and exclude his commit messages from the block chain until those
transactions expire, stealing all that value from the network.
Therefore the value of CPU resources dedicated to block computation
over any period of time must remain reasonably close to the value of
all circular transactions any participant or collaborating group of
participants could make simultaneously and allow to expire with that
period. That may not be feasible, and even if it is, it is probably
not very efficient.
The simplest solution from a protocol point of view is just to let
hosts build up trust with one another over time, perhaps by limiting
the value of promises they will accept from another host until they
become more confident they will not be cheated. If they are cheated,
they will just blacklist that host and have no more dealings with it.
If it gets bad enough, they could have a whitelist of hosts and
require security deposits from new hosts to accept promises from them,
and only accept promises up to the amount of the security deposit.
This may not be the simplest solution overall though.
Slightly more complex from a protocol point of view is to include in
the connection negotiation between two Ripple hosts a phase in which
they must agree on one or more third party arbiters who will resolve
any disputes over commit messages. If either host had a commit
message that it had to get to the other host before it expired, but
couldn't reach the other host, it would send the commit message to the
arbiter, who would attempt to reach the other host. If it also could
not reach the other host, it would timestamp the message, and then
present it to the other host when it came back online, as proof that
it must still fulfill its promise to pass forward value. The
timestamped message, combined with the other host's agreement to
submit to the authority of the arbiter, could also be used to sue the
other host for lost value if it got to that.
Even this solution isn't much use, though, if the other host simply
disappears without a trace. Possibly the commitment to fulfill value
could be linked to the owner of the node on the other host, but
perhaps this isn't always feasible. Note that this is also an issue
with the block chain solution. Even if you can prove you had the
commit message and tried to deliver it, it won't help if you can't
track down the owner of the other node.
So ultimately this problem seems to boil down to a matter of trusting
the host of the other node. If you already trust the other node
enough to grant it credit, then this is fine. If it wants to steal
from you, you have given it ample means already -- it can simply use
the credit and then renege on paying back its IOUs. It is still
useful to have an arbiter perhaps, if only to have a way to resolve
who must pay for value lost during incidental connectivity problems.
If you don't trust the other node -- if it has only granted you credit
-- then there is also no worry. It cannot pay through you until you
have used some of the credit it has granted you, and if it tries to
scam you by ignoring a commit message, you can simply renege on
repaying your IOUs and sever the connection with no loss to you.
Again, an arbiter might be useful just so you know if it was in fact
your own connectivity problem that caused your own loss.
One proposal to minimize the risk of loss during outages was to commit
the transaction bit by bit, so that no intermediary is ever on the
hook for a very large amount at any one time, in case they had an
outage. This has the drawback that a transaction might expire with
only part of the amount sent. The payer might retry, but it might
fail. The recipient might attempt to pay back the sent amount, but
that might also fail. The chances of this are slim, but it is
possible, and would eventually happen. The final recourse would be to
settle the remaining amount (or refund) in cash. I doubt it would
impress users very much to learn that their transactions might get
partly and irrevocably committed. So this probably isn't a very good
solution.
So maybe the best thing is just to enable hosts to negotiate a
mutually-agreeable arbiter to help them resolve any commit issues.
There is also the option of giving up real-time transactions in favour
of the block-chain commit model, like Bitcoin, where actual
transactions get entered into the block chain, and you don't count
them as committed until the block chain gets far enough past your
transaction that you are comfortable no one will be able to compute a
competing alternative chain that excludes your transaction. That
makes point-of-sale transactions potentially very awkward though.
Ryan
Ryan
(What server the payer is on is immaterial -- the recipient never
needs to trust the payer or his server.)
Human-level social relationships are important to consider when
reasoning about this issue. As I mentioned last time, if you do not
offer to trust your neighbour's IOUs, but she trusts yours, you are
not vulnerable, as long as you can detect cheating (which your
software can). It's when you have offered to trust your neighbour's
IOUs that you are vulnerable to this attack. However, since it is
simple for your neighbour to "cheat" you by simply defaulting on her
IOUs, the motivation for deception at the protocol level is to not get
caught, and be able to blame some unknown network or server error for
the missing value, and have you keep trusting her, as well as to avoid
any potential legal liability for your loss. The important thing,
then, is that you can detect when you are being deceived. If you can
do that reliably, then there your neighbour has nothing to gain by
deceiving you.
Suppose your node accepts a commit message, but the neighbouring node
who is before you in the payment path is unreachable all of a sudden.
You need to determine whether it is your server that is offline, or
the neighbour's. Thus the third party arbiter. If you cannot reach
the arbiter to prove you have the commit message before the
transaction expires, then it is you who are effectively offline and
then you must take it up with your server operator. If you can reach
the arbiter, and the arbiter can reach your neighbour, then the
transaction can continue normally by passing messages through the
arbiter. If you can reach the arbiter, but the arbiter cannot reach
your neighbour either, then you (or your server operator) must take
the issue up with your neighbour (or your neighbour's server
operator). If your neighbour (or their server operator) is unwilling
to make up for your loss, despite the arbiter's proof that they are at
fault, then you would end your trust relationship, blacklist that
server, and/or sue the neighbour or their server operator, depending
on the specific agreements that were in place between all parties
involved. Of course, you must know who your neighbour is -- but if
you offer credit to a node without knowing who owns it, then you are a
fool and deserve what you get.
Your neighbour's server might try to "frame" your neighbour, by making
a circular payment between two nodes it controls, through your
neighbour and you, and then stall the transaction at your neighbour,
knowing you would have to pursue your neighbour for the missing value.
For this reason, every user would have to trust their server
operator, either implicitly, or explicitly, through agreements where
the operator promises to take responsibility for these types of losses
when it is shown to be their fault.
More nefarious is server software that operates normally for long
periods of time, but occasionally stalls in the middle of a
transaction -- perhaps because it recognizes a transaction that will
profit the software maker if it doesn't complete. For this reason, a
server operator must be able to trust their software, either because
it is open source, or because the software maker insures against
losses due to software error.
The basic point I'm making is that since the arbiter system gives a
way to demonstrate objectively which user's server is responsible for
a stalled transaction, there is no incentive for a user to stall a
transaction on purpose in order to try to profit. If a server
operator insures its users against losses from stalled transaction
losses, then it has no incentive to stall transactions on purpose.
And if software is open source, or the maker insures against stalled
transaction losses (and given some way of determining it was the
software's fault), a software maker has no incentive to stall
transactions on purpose.
What remains is that, given a workable arbiter system and sufficient
server operator insurance, there is every incentive for servers to be
well-behaved.
(Note that the commit message block chain we've been discussing is
just a way to have an arbiter system without having to trust any
particular third party.)
What remains, though, is the fact that, in this real-time transaction
system, nodes or server operators can be on the hook for transactions
they didn't initiate if they happen to go offline in the middle of
intermediating a transaction. However, if there was a way for the
commit message to bypass the offline host and continue on back to the
payer, then when the offline host came back online, it could catch up
on what it missed without any loss. One option is to just broadcast
the commit message over the entire network. Another is to give a URL
where any intermediary can get the commit message.
This has all been discussed before, but I don't think I ever realized
that making the commit message available to all intermediaries at once
doesn't increase the incentive to misbehave -- it is still just as
easy to detect misbehaviour. So this might actually be enough.
If commit messages are broadcast, then some servers might decide to
timestamp and archive all the commit messages they see to help resolve
disputes. These could become the arbiters, and they might charge a
small fee to subscribe to their commit message archive. Over time,
widely-trusted arbiters would emerge, and then server operators could
decide to only insure against transaction losses on connections with
nodes on other servers who agreed to submit to an arbiter from their
list of trusted arbiters. This would ensure that servers could trust
each other.
This is the Ripple version of the Bitcoin block chain: Not one
canonical collective record, but just two participants agreeing on a
version from someone they can both trust. It doesn't matter if there
exists a canonically correct record of all commit messages, just that
any two participants can agree on a record that works for them. This
works because in Bitcoin value is strictly global, but in Ripple value
is strictly local.
Ryan
What originally brought me to ripple was that:
1. It could track debts
2. Debts can be used as currency, and to a degree, as money
3. It worked well with (and relied on) communities of trust
It was a simple concept and simple tool, focused on the social aspects
of exchange. I envisioned ways of using it with simple SMS cell phones,
or perhaps even with just voice calls to a village elder who would do
the actual data entry. I think society is likely to re-localize
somewhat, and I could see how ripple could be a part of that vision.
Recent discussions here have evoked visions of global networks of
computers facilitating anonymous commerce and allowing (or preventing)
arbitrage of exotic measures of value (like bitcoins and terra units).
That's not necessarily bad, but to me it is less interesting. I just
thought I should mention it in case this was not an intentional shift.
Or perhaps this high tech discussion is just a sidebar that I am putting
too much emphasis on.
Kevin
The latter -- a sidebar. Implementing distributed systems is
complicated, but that doesn't mean the user interface for it has to be
when it gets implemented. Technical discussions like this used to
happen on a different list, but they are happening more here now,
since there seems to be an audience for it. If you are not interested
in the technical details, please ignore. If it gets to be too much,
we should again consider moving these discussions to their own list.
Ryan
> Kevin
>
>
> On Tue, 2011-03-01 at 23:38 +0000, danny jp wrote:
>> And in case you are wondering how this picture differs from the
>> mainstream financial system, the answer is that there is no central
>> bank, and no regulations or barriers to setting up a bank node except
>> the problem of establishing a suitable reputation.
>>
>> So if payee node A is connected to bank node B, and that node B is
>> connected to bank node C, and the payer is connected to node C via his
>> own contact D, then the payment is routed almost entirely along
>> connections of high trust and high potential capacity.
>
>
>
Ok. As long as ripple users never see the word "bitcoin" (unless they
actually want a bitcoin-denominated account), it should be fine.
Thanks,
Kevin
Agreed. Sorry for the confusion. Context is everything.
Ryan
Recent discussions here have evoked visions of global networks of
computers facilitating anonymous commerce and allowing (or preventing)
arbitrage of exotic measures of value (like bitcoins and terra units).
That's not necessarily bad, but to me it is less interesting. I just
thought I should mention it in case this was not an intentional shift.
Or perhaps this high tech discussion is just a sidebar that I am putting
too much emphasis on.
I don't see any need for bank nodes to help solve this problem, but
rather *trustworthy servers*....
(What server the payer is on is immaterial -- the recipient never
needs to trust the payer or his server.)
If a server
operator insures its users against losses from stalled transaction
losses, then it has no incentive to stall transactions on purpose.
And if software is open source, or the maker insures against stalled
transaction losses (and given some way of determining it was the
software's fault), a software maker has no incentive to stall
transactions on purpose.
What remains is that, given a workable arbiter system and sufficient
server operator insurance, there is every incentive for servers to be
well-behaved.
(Note that the commit message block chain we've been discussing is
just a way to have an arbiter system without having to trust any
particular third party.)
What remains, though, is the fact that, in this real-time transaction
system, nodes or server operators can be on the hook for transactions
they didn't initiate if they happen to go offline in the middle of
intermediating a transaction. However, if there was a way for the
commit message to bypass the offline host and continue on back to the
payer, then when the offline host came back online, it could catch up
on what it missed without any loss. One option is to just broadcast
the commit message over the entire network. Another is to give a URL
where any intermediary can get the commit message.
This has all been discussed before, but I don't think I ever realized
that making the commit message available to all intermediaries at once
doesn't increase the incentive to misbehave -- it is still just as
easy to detect misbehaviour. So this might actually be enough.