Protocol /
CommitBlockChain
Protocol.CommitBlockChain History
Hide minor edits - Show changes to output
Added lines 1-2:
''This way of resolving commit message disputes is probably overly complex for Ripple. We don't need one canonical record of commit messages, we just need a way for any two nodes to agree on a third party to act as arbiter for any disputes.''
Added lines 1-2:
!! Idea
Changed lines 44-60 from:
connections' servers.
to:
connections' servers.
!! Block Chain Scope
A block chain should be not only for all nodes connected in the same isolated credit network, it should be for all nodes whose servers are connected in the same data network. There may be multiple disconnected credit networks using the same block chain. A single block chain per data network is stronger and more resistant to attack.
!! Fees
Anyone who wants a commit message included in the block chain can attach a processing fee to encourage its inclusion. It is not always useful to pay these fees with regular Ripple transactions, since a single block chain may span multiple disconnected credit networks, and IOUs between them may have no meaning.
One solution is to generate Ripplecoins similar to Bitcoins with each block, and allow those to be attached to commit messages as fees. Then, if the generating servers overall feel they are not receiving enough for their work, they can start dropping commit messages that don't include enough fees. This will motivate other servers that care about their messages being included to start including more Ripplecoins, driving up demand, and increasing their exchange value, increasing the reward that generating servers get for their work. This will motivate more servers to work on computing blocks, and ensure the block chain is as strong as possible.
!! Merging Networks
It's possible that two distinct data networks of Ripple servers exist, each with their own block chain. They might eventually merge by a connection between nodes from both. In this case, the more difficult block chain should take over, and all servers should work on extending that one. Those servers that care can still store the old one as proof of commit messages therein, if need be. Until the next difficulty target update, blocks will get computed faster.
Ripplecoins complicate the merging somewhat. One possibility is that the Ripplecoins from each network get assigned a new value equal to the total work that went into the chain they were generated from, relative to the other chain.
!! Block Chain Scope
A block chain should be not only for all nodes connected in the same isolated credit network, it should be for all nodes whose servers are connected in the same data network. There may be multiple disconnected credit networks using the same block chain. A single block chain per data network is stronger and more resistant to attack.
!! Fees
Anyone who wants a commit message included in the block chain can attach a processing fee to encourage its inclusion. It is not always useful to pay these fees with regular Ripple transactions, since a single block chain may span multiple disconnected credit networks, and IOUs between them may have no meaning.
One solution is to generate Ripplecoins similar to Bitcoins with each block, and allow those to be attached to commit messages as fees. Then, if the generating servers overall feel they are not receiving enough for their work, they can start dropping commit messages that don't include enough fees. This will motivate other servers that care about their messages being included to start including more Ripplecoins, driving up demand, and increasing their exchange value, increasing the reward that generating servers get for their work. This will motivate more servers to work on computing blocks, and ensure the block chain is as strong as possible.
!! Merging Networks
It's possible that two distinct data networks of Ripple servers exist, each with their own block chain. They might eventually merge by a connection between nodes from both. In this case, the more difficult block chain should take over, and all servers should work on extending that one. Those servers that care can still store the old one as proof of commit messages therein, if need be. Until the next difficulty target update, blocks will get computed faster.
Ripplecoins complicate the merging somewhat. One possibility is that the Ripplecoins from each network get assigned a new value equal to the total work that went into the chain they were generated from, relative to the other chain.
Added lines 1-42:
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.
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.