Bitcoin-like implementation of Ripple
Timón
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.
Timón
Romualdo Grillo
many good Ideas in what you write.
I think Bitcoin is Based on two concepts (Correct me if I'm wrong, I'm
not a BitCoin expert.):
1) Issuing money: Proof of Work
Everyone can "Issue" or Generate a coin by proving he has done a
certain work (solving a problems that requires a predictable cpu
time)
2)Spending money: Block chain
A owns the coin XYZ, he broadcasts a message saying "I give the coin
XYZ to B", B becomes the new owner and can spend the coin broadcasting
another message.
In a Ripple system in most cases we do not need "Proofs of Work".
On the contrary "Block chain" can be useful for Ripple: in my opinion
it is possible to build a decentralized ripple system based on Block
Chain.
Many persons in this forum have worked on a distributed ripple
protocol, but we still do not have a real prototype.
Timon in case you did not try to give a look to this presentation:
http://docs.google.com/uc?id=0B8dIhu2cdQwsMWE4NzAwYjAtOWM3Ni00ZDZjLWFmYzEtMmJlNmIwYmFhY2Vh&export=download&hl=en
Romualdo
Timón
The proof of work is needed in order for everybody to know what is the
longest chain. All the nodes will continue the longest chain.
The work doesn't have to be paid. All the nodes are competing for
generating the next block, so the probability of generating the next
block (and taking the created bitcoins incentive) is proportional to
the work spent.
The proof of work is needed to maintain the decentralized timestamp
server.
I'll read the document, thank you.
>
> Romualdo
Timón
"broadcasted" transactions and prevent double-spending.
In Ripple, the credit A gives to B shouldn't be double-spent.
Ryan Fugger
Bitcoin community will take it up, because part of the what a lot of
people seem to like about Bitcoin is that the currency is issued
without debt -- it's a commodity currency, the commodity being
hard-to-compute sequences of bits. But it's certainly worthy of
discussion here, because Bitcoin has implemented a successful
decentralized distributed transaction system that we might emulate.
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.
>
>
Jeffrey Cliff
Jeff Cliff
Ryan Fugger
> 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.
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
Ryan Fugger
* 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
Ryan Fugger
> * 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.
>
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
danny jp
Agreed - that makes a hell of a lot of sense.
Ryan Fugger
of the ideas I mentioned in this thread yesterday, as well as a few
new ones:
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
danny jp
Ryan
Timón
and you you're going to use it in the next version of the ripple
protocol, although you're adapting them. I'm sorry I couldn't answer
sooner. Now I'm going to answer post by post.
> 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.
The debt network (DN) is contained in the block chain, but the credit
network (CN) is not completely contained in the block chain.
The clients (not the nodes) can send to each other credit blocks (or
credit transactions, CB) that are the edges in the Credit Graph. A
credit Block would contain the following:
-The address of the issuer of the credit
-The address of the receiver of the credit
-The maximum quantity of credit
-The number of block (in the block chain) from which this CB is valid
(this number and the addresses should be unique in the block chain).
-The number of block (in the block chain) in which the CB stop being
valid.
-The signature of the issuer of credit.
A client would store only the CB that are interesting to him, building
a subnetwork (of the CN) with its addresses (a single user can have
multiple addresses) and extending it as it can in order to be able to
pay to the higher number of different addresses possible. When a
client wants to pay some quantity to a concrete address, the client
looks for that address in it subnetwork. If it doesn't exist there, it
can still ask other clients for CB containing the target address as
issuer of credit, then ask for CB containing the addresses (as
issuers) that where receiver in those previous CB and so on.
It's possible that the user can't pay to some address. If he finds a
path from one of his addresses to the target, then he can build up the
transaction.
The transaction will contain all the CB needed to perform it. Note
that he doesn't need the owners of the addresses in between to be
online because the CB are already Signed by them.
When a transaction is prepared (by a client), is sent to the Nodes so
they can include it in the next block.
The nodes have to check (as in bitcoin), that the transaction does not
conflict with the previous blocks in the chain, the difference with
bitcoin here is that the rules are more complex.
Once a CB is in the Block Chain, it becomes public (the clients cannot
be forced to answer with CB when they're asked by other clients).
Anyone can use it while the debt does not exceed the maximum quantity
of credit, the debt does not go below zero and the expiration block is
not reached.
Once the expiration block is expired, the CB can only be used to
reduce the debt. After that moment it can be used until the bedt goes
to zero.
> 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've just read this paper:
http://www.bitcoin.org/sites/default/files/bitcoin.pdf
> 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.
turned off for a while and when they come back, just trust the longest
chain.
The clients can use the "Simplified Payment Verification" described in
the document of the link above.
> 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.
client is quite light.
I didn't think deep enough about exchange rates yet. I have to
understand first how that works currently in ripple.
> 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.
commenting anything.
The next thing I'll do is answer your next message. I read all of them
but I want to read them slowly before answering.
I'm sorry but you'll have to be patient.
Timón
> > 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.
>
> 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.
address accept IOUs from the other.
There's a "Credit Block" (as in my previous post) signed by the
address that gives the credit and containing the address that receives
it.
My solution was that the debts to the nodes in concept of fees doesn't
need the CB and these IOU must be accepted for any participant in the
network.
That is, these IOUs don't need CB from the sender to the receiver to
appear in a transaction that will be considered "legal" by the nodes.
Of course, the IOUs can be sent to the original issuer address. Then
the debt will be settled and the IOU destroyed.
But some sellers could say that they don't accept these special IOUs
as payment for a good or service although the network accept them.
Daniel's proposal in the bitcoin forum (as I understood it) was to
allow the nodes to issue bitcoins (instead of charging fees) and let
those bitcoins be used in the ripple economy.
Those bitcoins could be not accepted by the sellers too. And you're
are creating money that is scarce and therefore likely to have
interest.
Your solution seems more reasonable to me, but it has flaws too.
One is that the computer effort of the nodes is increased as they now
have to ask for CB and maintain a Credit network in memory in order to
estimate the value of the IOU.
Another is that is harder for a client for his transactions to be
treated as acceptable for the nodes. It can take more time for a
transaction to be accepted by a node.
Anyway, in this case, there's no need for special IOUs since the Node
can Sign the CB that allows the transaction to be legal. That credit
block can contain as receiver of credit directly address of the payer
of the fee or any other address involved in the transaction if the
transaction is still legal.
The sender of the transaction can send more CB than needed in the
transaction to facilitate the Node to create a transaction for paying
the fee.
I don't know if I'm clear enough, but I don't see this problem that
big now.
> > 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.
danny jp
> IOU from him/her. "
Ryan Fugger
> Your solution seems more reasonable to me, but it has flaws too.
> One is that the computer effort of the nodes is increased as they now
> have to ask for CB and maintain a Credit network in memory in order to
> estimate the value of the IOU.
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
Jorge Timón
>> IOU from him/her. "
>
> work rendered, otherwise you wouldn't do the work.
>
> Obviously if its an out of the blue gift then who cares, but that is not the
> case here.
>
> The price of computing the next block needs to be high enough that there
> will never be a shortage of volunteers to compute it otherwise the system is
> easily defrauded.
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.
danny jp
I can imagine a deployment of ripple (or a bitcoin derivative) in which all participants are expected to be online at least T% of the time, and to successfully solve the next block between B1% and B2% of the time.
One way to address this (in some greater ripple future) is to have participants purchase a $30 ripple dongle which is a small singleboard computer like Gumstix (but cheaper) that just plugs into a free port on your router (or someone else's router). Its one dongle per account, and each dongle has the following Bill of Materials:
1) Texas Instruments Embedded DSP processor for all crypto plus running a simple webserver.
2) enough DRAM to hold blocks in RAM (is this possible for reasonable cost?)
3) ethernet connector
4) power supplies etc
So I think its not that important perhaps to solve the issue of nodes being offline and/or freeloading. What is a bit trickier is to ensure that the computing power of the dongles can't be swamped by an attacker, but perhaps that could be solved somehow by only allowing each account to solve blocks a certain percentage of the time even if it can solve more than that. For that dongles would need their own IDs which are issued when the dongle joins the network by which ever node solves the next block.
Timón
I'm sorry, but I don't understand this last post.
@Ryan
I'm sorry, but daniel have convinced me that his solution to the
"incentive problem" is better.
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.
Ryan Fugger
> I'm sorry, but daniel have convinced me that his solution to the
> "incentive problem" is better.
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
Jorge Timón
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.
I've started a thread about it in the bitcoin forum. But be careful, I'd say some of them would happily beat me for suggesting deflation is bad:
I understand them. They want to get rich by holding bitcoins. I've bought bitcoins and silver too. I would buy gold too, but I got not enough money to buy an ounce. I guess that makes me a "Bit bug" and a "Silver bug".
They're better than Euros, but I don't want them to be the money of the future because they're deflationary and have interest.
I link you to the thread:
http://www.bitcoin.org/smf/index.php?topic=3816.0
The inflation/deflation is very important for me as well the removal of the interest.
That's the reason I love Ripple.
The "keep the government out" is the reason I love Bitcoin.
----------
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.
I like how that sounds. I have to read deep your real-time version.
danny jp
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.
danny jp
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.
Ryan Fugger
>
>
> The solution of Daniel does not involve fees to the Nodes. The nodes get the
> created money.
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
Sepp
I understand that bitcoin, in this proposed implementation in Ripple,
is going to be more than just an auxiliary mechanism to facilitate the
routing of payments, but might also serve one of the currencies that
are acceptable for payment.
Ideally, as a currency, bitcoins should keep a more or less constant
value. In the bitcoin implementation, as Jorge says, it is
deflationary, meaning each coin will become more and more valuable as
time passes. This is because the creation of coins is expected to lag
behind the increase in business. Bitcoin is arranged to have a fixed
target quantity of coins, and a constantly increasing difficulty of
calculation of the blocks, so that in the beginning, many blocks are
generated, changing to fewer and fewer blocks generated, until
eventually the fixed target quantity is reached. All the while, the
number of users is expected to keep increasing.
In order to avoid both inflation (over-creation of coins) and
deflation (under-creation of coins) the *target quantity* of creation
of coins should be adjustable. It could be linked to the number of
active nodes running the program, which gives a good approximation of
the amount of business to be done using the coins. Making calculation
of new blocks increasingly more difficult as the target quantity is
more closely approached, acts to distribute the creation of new coins
over time. Together, the adjustable target quantity and the increasing
difficulty of creation would act to soften any sudden changes, while
keeping a reasonably constant value of the currency itself.
Sepp
Jorge Timón
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. 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>:
danny jp
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.
I agree about the liquidity premium. Any system that attains balanced inflation and deflation has a liquidity premium of zero, e.g. the interest rate is zero. If the base interest rate for holding money (not debt) is positive, then that implies there is not enough of it. If the base interest rate for holding money is negative (in the nominal sense) that implies there is too much of it.
I would have more sympathy for negative nominal interest rates if they were just one outcome of an interest rate that floats above and below zero, above when the system is growing and demand to borrow is rising, and negative when the system is contracting and demand to borrow is falling.
However, all that only make sense in the context of a centralised control system, and as such any statements about interest in a decentralised P2P system like ripple are not appropriate, however it may be appropriate at some point in future to provide facilities for nodes to agree bilateral contracts between themselves that involve interest.
In ripple, each node will experience a personal interest rate determined by the credit capacity on his links. For saving, determined by how much and at what rate his connections are willing to borrow, and for borrowing, by how much and at what rate his connections are willing to lend him.
Therefore there is no possibility of having a system wide interest rate in ripple. Any kind of charge could only be applied to transactions.
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.
I'm familiar with Gesells work. In fact keynes said in his general theory that the future likely had more to learn from gesell than marx, a fact which is often overlooked.
What I am saying is that in a system of P2P lending and borrowing, effective negative interest rates would emerge spontaneously, but only in relation to individual nodes.
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.
yes.
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.
Lets distinguish between two types of fee:
1) the fee to have your transaction included in the block chain
2) the fees nodes may charge one another to have transactions routed through them.
The latter is totally free market.
The former is free market because its embedded in the software that you agree to use when you sign up with the network. You are not forced to join up, but when you do so, by implication you accept the rules.
Ryan Fugger
it is about a very important part of the protocol, but it actually is
quite a small part. 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:
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
Ryan Fugger
> First of all, I want to emphasize that this discussion may seem like
> it is about a very important part of the protocol, but it actually is
> quite a small part. 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:
>
> 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.
>
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
danny jp
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
Jorge Timón
We all agree in these things:
1) Ripple can be implemented in a distributed fashion using proof of work.
2) The intentive problem can be addressed by letting the generator of the block issue a currecy (ripplecoins).
There's a few differences between our views:
1) Price stability. Solutions:
A) Deflation is not going to be a problem (bitcoin)
B) Fees must be payed with each transaction. No one earns these fees, they're destroyed (Danny)
C) Fees aren't necessary. ripplecoins are destroyed using demurrage (Timón)
D) Fees are payedInflation is not going to be a problem (Ryan)
E) Fees are payed to the generator nodes. A percentage of the fee is destroyed (a hybrid between Danny and Ryan)
In cases B, C and E, the relation ripplecoins created/ ripplecoins destroyed should be dependant on something with didn't talk about yet. Sepp proposes the number of actives generating nodes.
2) Making ripplecoins valuable
A) Fees must be payed in Ripplecoins (Danny and Ryan)
B) Fees must be accepted to settle debts. (Timón) I admit I got my doubts on this. How and when the exchange between currencies would take place? In this case, price stability gets more important. Althougt this is not adpted, I think we should define a type of transaction in which debts are settled through payment of ripplecoins by the debtor (The sign of both parties can be required).
3) Always online problem
A) Ryan has a solution that I don't understant well yet. It has to do with subnetworks called cells.
B) Credit elements with an expiration block number and signed by the creditor are created and shared between clients. Different
clients can have differnt rules and mechanisms (encryption can be used) for this sharing.
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. 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.
danny jp
Ryan Fugger
> 3) Always online problem
> A) Ryan has a solution that I don't understant well yet. It has to do
> with subnetworks called cells.
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
danny jp
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.
Ryan Fugger
>
> I am thinking of a situation in which the ripplecoin supply in your proposal
> is generally some way in excess of that which is needed for reward of new
> block computation, so less CPU becomes dedicated to doing that. At which
> point, the network is more vulnerable to an attacker.
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
Ryan Fugger
determining processing fees: If you're a processor, watch the commit
messages being broadcast for inclusion in the block chain and keep a
moving average of the fee per commit message. Anything equal to or
above the average gets included in your block, and anything below the
average gets included with probability proportional to its closeness
to the cutoff. Maybe messages with zero fee get included with 50%
probability, messages with half the average get included with 75%
probability, all the way up to the average, which gets included with
100% probability.
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.
Ryan Fugger
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
danny jp
Ryan
danny jp
danny jp
Ryan Fugger
rather *trustworthy servers*. In other words, it doesn't matter who
owns the node in this case, but rather *who operates the server*, and
what software do they run? If you can trust the server operator and
the software, the user is not able to attempt to cheat by pretending
to ignore commit messages. Therefore merchants might decide to only
form accounts with users on known trustworthy servers. More on this
below...
(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
Kevin
ripple (or at least the focus of this list) seems to have shifted from
"low tech" to "high tech".
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
Ryan Fugger
> 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.
>
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.
>
>
>
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.
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
Ryan Fugger
> Ok. As long as ripple users never see the word "bitcoin" (unless they
> actually want a bitcoin-denominated account), it should be fine.
>
Agreed. Sorry for the confusion. Context is everything.
Ryan
danny jp
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.
danny jp
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.