Technical proposal: commit registries
Ryan Fugger
draft's idea of commit arbiters, whose purpose is transaction
atomicity in the face of server outages, either real or pretend. I'm
now calling them "commit registries" instead of "arbiters".
When a node puts forward a credit-reserving promise, it can specify
one or more "commit registries" who can, by timestamping and signing
the commit message, authoritatively declare that the promise must be
redeemed. This is to reassure the promise holder that it won't get
stuck holding a commit message that it has bought, but cannot sell
back down the payment chain because it cannot reach the node who
issued the promise before the promise expires. The registries also
publish the timestamped commit messages so a node can look up whether
its promise has been triggered, even if it cannot communicate with the
neighbour who holds the promise.
Evgeni pointed out to me, though, that this still doesn't solve the
problem of a node that goes offline while holding a commit message
that it hasn't cashed in or had timestamped yet -- it will have to eat
that cost if it isn't able to get the commit timestamped before the
promise expires. The natural thing for a node to do, then, is to want
the commit message to be already timestamped by a suitable registry
for triggering the promise it holds when it receives the commit, so
there is no risk in accepting the commit.
The way to get transaction atomicity, then, is for all the
participants to agree on a set of commit registries that can timestamp
the commit message, and have the recipient get it timestamped before
sending it back down the chain. In other words, for atomicity, every
intermediary should require the same registry timestamp(s) to trigger
its promise as the previous intermediary offers will (or requires to)
trigger its promise. This changes the dynamic from the current draft
where the use of arbiters/registries is offered by the promisor and
optionally taken up the promise holder, to one where the use of
registries might be *required* by the promisor.
If a promise expires without a commit message appearing down the
chain, the intermediary who issued the promise would have to check
with the registries to see if a commit message for the transaction had
been registered, and if not, it could let the promise expire. To
avoid the possibility of deception, the registries should sign a
"non-commit" message stating that at the time stamped, they did not
possess a commit message for the given transaction ID. That way, if a
registry cheated and stamped conflicting commit and non-commit
messages, it could be demonstrated for all to see.
As an optimization when requesting a non-commit statement, a node
would specify its promise expiry time, so the registry could re-use
any existing non-commit it had already generated as long as the
timestamp was after the promise expiry.
Transaction IDs would be the hash of the payer's commit key, which
would be included in the commit message, to avoid the possibility of
registering bogus commits for open transactions.
Generally a single registry would suffice for atomicity, but multiple
registries would be permitted for added robustness: For a commit to
be valid, it would have to be stamped by *all* the transaction
registries, so that only a single non-commit from one of the
registries is enough to rollback. This minimizes the possibility of
having credit tied up indefinitely if a registry is non-responsive and
the recipient does not issue a promise-release. Using multiple
registries would not add significant delay to the transaction, since
registry timestamps can be acquired in parallel. If a registry
becomes non-responsive mid-transaction, the recipient would release
the promises and communicate to the payer to retry without the
non-responsive registry. In the unlikely event that all registries
become non-responsive, and the recipient does not issue a
promise-release, then it will fall to server operators to come to an
out-of-band agreement on how to reclaim the frozen credit.
Nodes would advertise which registries they trusted, whether they
required a registry on incoming transactions, and whether they would
accept non-timestamped commits, so payers could route accordingly.
This would allow as much as possible for the system to work on paths
where no common registry exists (including nodes that do not trust any
registries), while still maintaining atomicity for partial chunks
where possible.
Registries would be advertised in the network in a similar way to
nodes. Anyone could advertise a registry. Registries might require a
login to perform signatures (so they could charge fees for service),
but should publish their timestamped messages publicly. The protocol
for interacting with a registry (likely a HTTP/REST API) would be
standardized and included in or alongside the Ripple protocol
document.
The result is a mechanism by which all transaction participants can
agree to be bound together to either commit a transaction or roll it
back. Unlike a Bitcoin-style blockchain, it does not require a time
delay to achieve certainty either way.
Anyone have any thoughts on this?
Ryan
danny jp
--
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.
Ryan Fugger
> I think this is a very useful proposal technically. But the obvious
> non-technical issue with it seems to be that even if all parties agree to
> the registry to be used, that doesn't reduce the danger of a mid-chain
> default if that default is not just due to some network outage.
No, that's an trust issue outside the protocol.
> It seems inevitable that this registrar must be conflated with some kind of
> credit scoring or insurance.
No, that's an entirely different issue. The registry only ensures the
transaction is committed. Whether the obligations exchanged actually
have the value presumed by the participants doesn't affect this at
all.
> I wonder what's in it for the registry service?
As I mention in my email, registries can charge fees.
Ryan
Ryan Fugger
> Sounds good to me.
>
> In principle anyway, is there any reason why each account in the
> transaction couldn't use a different timestamp registry?
>
Each step could use a different registry, but there's no guarantee of
overall atomicity that way. It's risky for a node not to require the
same registry of the neighbour ahead as offered by the neighbour
behind, since there is some extra communication required for them to
redeem their promise in time. But it's still better to have that
option than to not have any registry at all.
Ryan
danny jp
No, that's an entirely different issue. The registry only ensures the
transaction is committed. Whether the obligations exchanged actually
have the value presumed by the participants doesn't affect this at
all.
Jorge Timón
> chain would need to be connected to the registry node, with the commit chain
> nodes having to be trusted by the registry for sufficient credit to cover
> the fee payable.
Can't the payer pay all the fees?
> In which case one wonders what the registry node would do
> with all these microcredits - i.e. how it would realise value from them in
> practice, and also how it would come to a position where it was willing to
> trust a given participating node in the first place.
Registries trusting nodes to be able to receive fees is an issue. I
guess most registries would be also regular nodes.
For exaple, a could have a registry node that I trust to make my
payments. Then I pay myself the fee to to make the payment.
Wait a minute. If it would work with just one registry, and that
registry can be the payer, ¿Why doesn't the payer replace the
registries functions?
If I'm based in wrong premises about how it works, What am I missing?
danny jp
Can't the payer pay all the fees?
¿Why doesn't the payer replace theregistries functions?
danny jp
Jorge Timón
>>
> That is an idea worth exploring.
> However I think that an attempt to ensure whole transaction atomicity in
> ripple is a bit like trying to exceed the speed of light.
Well, it is completely neccesary.
I thought two phase commit can have it and public bitcoin-like
transaction chain too.
>The 'ripple
> paradox' is that the system offers in theory infinite liquidity yet in
> practice the amount of liquidity is restricted by peer to peer trust
> capacity. Schemes which require trusted third parties to increase the
> potential liquidity beyond this fundamental limit seem to me to break the
> spirit of ripple and will end up sooner or later recreating a bank or
> central bank or some other powerful entity.
I agree. I think arbiters must be out of the ripple protocol. They can
provide their services on top of it.
For example, one ripple related bussiness that I'm thinking on lately
can rely on the spanish ID card's ability to sign digital documents.
I'm not a lawyer, but maybe it can be used to make people reliable for
the IOUs they issue with a certain node/key pair. Probably this last
thing should be in another topic.
The arbitrage that Ryan proposes here, I think, is intended just as a
mean to facilitate two phase commit. Hopefully this registers won't be
much powerful than trackers in eDonkey but I understand and share your
concerns.
> But I'm not sure transaction atomicity is really needed. Presumably
> transactions are effectively atomic among nodes on the same server so I
> would have thought that all that is required is that people trust all the
> servers in the chain and that servers don't go down regularly.
What's the point in distribution then?
If everyone has two trust every server, they could just use the same
one and have instant and atomic transactions.
Evgeni Pandurski
I like this idea. A transaction can be split into many sub-transactions,
staring with small amounts, and increasing them with time. The idea is that
the amount of each successful sub-transaction serve as a collateral for
the next transaction (like the way TCP increases the window-size).
The problem with this is that you do not get proper atomicity -- if you
want to transfer $1000, you may end up with $556.12 transferred,
with no chance to transfer more or rollback. But in many cases this
is OK.
danny jp
I like this idea. A transaction can be split into many sub-transactions,
staring with small amounts, and increasing them with time. The idea is that
the amount of each successful sub-transaction serve as a collateral for
the next transaction (like the way TCP increases the window-size).
The problem with this is that you do not get proper atomicity -- if you
want to transfer $1000, you may end up with $556.12 transferred,
with no chance to transfer more or rollback. But in many cases this
is OK.
Evgeni Pandurski
>>
>> I like this idea. A transaction can be split into many sub-transactions,
>> staring with small amounts, and increasing them with time. The idea is
>> that
>> the amount of each successful sub-transaction serve as a collateral for
>> the next transaction (like the way TCP increases the window-size).
>>
>
> There would need to be some protocol via which the maximum sub-transaction
> size is negotiated amongst all the participants.
> Increasing window size could certainly be done but would the increase in
> efficiency be worth paying the setup cost and extra initial negotiation
> effort? Also I 'm not sure you can use the previous success as collateral to
> justify a size increase because whether a server goes down or not is
> (mostly) unrelated to the number of successful previous transactions.
The idea is that if I have promised $100 to you (for this I was paid by someone
else), I can issue another promise-message for $100 to you, because if you
decide to not release my promise for long time, I will be able to tax you from
the money I owe you. So even if I do not trust you at all, I am still confident
to make potentially long-term promises to you (locking down some resources).
So, basically I can double the promise I make to you each time.
danny jp
Ryan Fugger
> So lets assume that a promise has been entered in a registry,
Promises aren't entered into registries. Promises specify which
registries are eligible/required to timestamp the commit.
> then a node in
> the chain decides not to play ball regardless of the fact that everyone can
> see it has agreed to do so. What chain of events would follow?
If a node does not fulfill its promise (ie, pass an IOU message
forward) despite being presented with a commit that matches the
promise requirements, then it is considered a default, which the
promise holder must deal with out-of-band.
It is actually pointless for a node to refuse to pass an IOU, because
an IOU is no more meaningful than a promise once a valid timestamped
commit exists. Defaulting on a IOU is no different than defaulting on
a promise to pass an IOU. The IOU is simply an acknowledgement of the
validity of the commit. In other words, the act of presenting a valid
commit brings a moral obligation into existence, whether the promisor
acknowledges it with an IOU or not.
How two account partners handle a default is up to them. The promise
message and the valid timestamped commit give the promise holder proof
of the promisor's obligation, whatever that means under their implicit
or explicit account agreement.
> In any case, the other thing that I am now thinking is that if registries
> are charging fees in domestic currency, then it defeats the purpose of
> ripple since a currency transfer mediated by a commercial bank would be
> needed for each stage in the chain.
If I ran a registry, I would charge a monthly or yearly fee for a
particular level of service (eg, number of timestamps), or deduct a
small amount from each user's balance for each timestamp
(micropayments), so transfers would be infrequent.
> If registries are charging fees in ripple, then each node in the commit
> chain would need to be connected to the registry node, with the commit chain
> nodes having to be trusted by the registry for sufficient credit to cover
> the fee payable. In which case one wonders what the registry node would do
> with all these microcredits - i.e. how it would realise value from them in
> practice, and also how it would come to a position where it was willing to
> trust a given participating node in the first place.
There's no need for registries to deal with nodes individually. They
can just deal with servers.
If a server could pay me in Ripple, great. If not, I'd take dollars.
I'd offer services for free at first to build trust, and then only
charge high-volume users once it became too costly to run the
registry.
> Is there an alternative scheme in which a node in the commit chain
> timestamps messages for other nodes somehow? E.g. the timestamping
> responsibility for each element on the commit chain propagates in the
> opposite direction to the direction of promises?
Sure, that's the protocol without registries. Transactions aren't
atomic though.
2011/4/17 Jorge Timón <timon....@gmail.com>:
> Can't the payer pay all the fees?
>
Yes, I'm sure any registry fees will be passed back to the payer via
normal transaction fees.
> Registries trusting nodes to be able to receive fees is an issue. I
> guess most registries would be also regular nodes.
Registries will be separate entities from nodes. They don't have
credit connections. Registries will most likely be operated by Ripple
server operators.
> For exaple, a could have a registry node that I trust to make my
> payments. Then I pay myself the fee to to make the payment.
> Wait a minute. If it would work with just one registry, and that
> registry can be the payer, ¿Why doesn't the payer replace the
> registries functions?
> If I'm based in wrong premises about how it works, What am I missing?
>
The payer's server operator might also operate the registry for a
transaction, sure. But in general we can't assume that every
intermediary trusts the registry operated by the payer's node's server
operator, so it's better to allow for any registry to be used.
> However I think that an attempt to ensure whole transaction atomicity in
> ripple is a bit like trying to exceed the speed of light. The 'ripple
> paradox' is that the system offers in theory infinite liquidity yet in
> practice the amount of liquidity is restricted by peer to peer trust
> capacity. Schemes which require trusted third parties to increase the
> potential liquidity beyond this fundamental limit seem to me to break the
> spirit of ripple and will end up sooner or later recreating a bank or
> central bank or some other powerful entity.
Using 3rd-party registries doesn't increase liquidity one bit. It
actually decreases liquidity, since it limits the number of viable
payment paths to those that share a common trusted registry. This
decrease in liquidity is my main concern with the scheme, which is why
it's only an optional part of the protocol.
> But I'm not sure transaction atomicity is really needed. Presumably
> transactions are effectively atomic among nodes on the same server so I
> would have thought that all that is required is that people trust all the
> servers in the chain and that servers don't go down regularly.
If every intermediary knows and trusts all the servers in the chain to
cooperate on making sure transactions are committed properly, then
registries aren't needed for that transaction. However, registries
provide a default mechanism for this cooperation to take place.
Otherwise, dealing with communication outages is left to the server
operators to handle manually.
I'm falling behind this thread, so I'll just send this and answer the
other messages in another email.
Ryan
Ryan Fugger
I had this in an earlier protocol version, but I don't like it because
if a transaction stalls with half the amount committed, you have to
then organize a refund, possibly over the same path that just stalled.
Not a good design.
> I agree. I think arbiters must be out of the ripple protocol. They can
> provide their services on top of it.
The protocol for Ripple servers to communicate with registries will be
quite separate, but there must be hooks in node advertisement to
declare trusted registries, in the promise message to declare
acceptable/required registries, and in the commit message to allow for
registry timestamping. It's not nice and separate, unfortunately, so
it must be accommodated in the protocol to a certain extent. This
doesn't bother me too much, since it provides the only mechanism I've
seen for real-time transaction atomicity, which is a very important
feature, IMO.
Ryan
danny jp
> particular level of service (eg, number of timestamps), or deduct a
> small amount from each user's balance for each timestamp
> (micropayments), so transfers would be infrequent.
But the user nodes would need to have such an account at nearly all
the registries in operation for there to much chance of a commit chain
all being able to use a given registry.
danny jp
This
doesn't bother me too much, since it provides the only mechanism I've
seen for real-time transaction atomicity, which is a very important
feature, IMO.
Ryan Fugger
> But the user nodes would need to have such an account at nearly all
> the registries in operation for there to much chance of a commit chain
> all being able to use a given registry.
>
Which is why new servers would want to work with the same registries
that existing servers do, as long as those servers are affordable and
reliable. It will be technically simple to launch a new registry, but
it would involve getting a lot of major servers on board off the bat,
and there wouldn't be much point in doing so as long as existing
registries were performing their function acceptably. If there was
too much registry fragmentation, there be pressure for the registries
themselves to form associations to help simplify access somehow. And
if there was too little choice, there would be an opening for new
registries to establish themselves. I think it's possible and even
likely it will balance itself out.
> You seem to be saying that people wouldn't enter into transactions without
> this feature in many or most cases, which is what I meant when I said that
> this feature (atomicity) is designed to increase liquidity (beyond the
> limits I have suggested are fundamental to ripple). That is, without this
> feature liquidity would be reduced because transactions could not be
> initiated in the first place.
> It can't be reducing liquidity because although the feature restricts the
> number of viable transactions, its necessary existence would imply that
> without it then even less or maybe no transactions would occur.
Good point. Yes, it will increase liquidity in the sense that it will
ultimately enable more people to participate in the network, and make
connections easier to make, since the chance of needing to resolve
commit disputes with neighbouring servers will be drastically reduced.
> There is another solution to atomicity perhaps. What if when an atomic
> transaction is required all the participants moved their accounts to a
> special server for the transaction, and then moved back? We discussed the
> process for moving accounts a while back, but I'm not really sure how time
> consuming this process might be - not very, it seemed to me. Obviously if a
> node was holding other promises pending expiry or resolution this wouldn't
> be possible, and it would make real time atomic transactions tricky, but I'm
> not sure why this feature is considered so key, and in what situations it
> might be deemed necessary.
>
That's a strictly less effective solution than registries, I think,
since it still requires all transaction participants to trust a single
third party, but it requires them to trust it more strongly. The
implementation is also more complex.
Ryan
danny jp
> it would involve getting a lot of major servers on board off the bat,
> and there wouldn't be much point in doing so as long as existing
> registries were performing their function acceptably. If there was
> too much registry fragmentation, there be pressure for the registries
> themselves to form associations to help simplify access somehow. And
> if there was too little choice, there would be an opening for new
> registries to establish themselves. I think it's possible and even
> likely it will balance itself out.
The fragmentation would be determined by competitive pressure. If
there are two few registries the price for their services would be
high. If there were too many not only would there be no profit but
also there would be problems for users to agree on a common registry
service.
I think this process you have outlined represents either a dangerous
monopolistic chokehold on ripple payments, or a debilitating barrier
to actually making payments at all, or both.
I still don't understand what the main reason to require atomicity is,
and what types of transaction might need it. I think we already agreed
that ripple can't compete with the commercial banking and payments
systems, and that ripple should target underbanked users or markets
where the commercial systems can't or won't go.
Given that, I think the specific needs for atomicity needs to be clarified.
> Good point. Yes, it will increase liquidity in the sense that it will
> ultimately enable more people to participate in the network, and make
> connections easier to make, since the chance of needing to resolve
> commit disputes with neighbouring servers will be drastically reduced.
So the really important question is, what additional class users does
atomicity include, as opposed to a non-atomic solution and would
ripple compete with the commercial financial system for these users?
I think that if a given use case requires a variety of pseudo-bank
functions that these use cases might be best left to the commercial
payments systems, or to a later version of distributed ripple.
> That's a strictly less effective solution than registries, I think,
> since it still requires all transaction participants to trust a single
> third party, but it requires them to trust it more strongly. The
> implementation is also more complex.
Well yes and no. Because the moving to a temporary host is a temporary
arrangement for a single transaction while the annual fee based
mechanism for paying registry fees is a much more extensive
commitment.
The additional complexity of host-hopping is matched IMO by the
whole-ecosystem complexity of the registries. Atomic transactions are
going to be complex and somewhat costly whichever way they are
implemented.
Which brings me back to the chunking system. While this presents a
possible danger to the payer (who may end up having transferred only
part of the required payment), it makes things a lot easier and less
risky for the intermediating nodes who reduce their worst case loss to
a single chunk. I think that a key issue with ripple is incentivising
intermediary nodes to participate, otherwise a transaction cannot even
be initiated, and that therefore we should bias ripple to slightly
favor intermediating nodes over the seller and buyer in order to
maximise available liquidity, which IMO is ripple's unique selling
point.
Danny
Ryan Fugger
> I think this process you have outlined represents either a dangerous
> monopolistic chokehold on ripple payments, or a debilitating barrier
> to actually making payments at all, or both.
>
As you just pointed out to me, the existence of registries only
enables more participants and more payments. It can't by its nature
prevent any payments that would happen in a system without registries.
> I still don't understand what the main reason to require atomicity is,
> and what types of transaction might need it. I think we already agreed
> that ripple can't compete with the commercial banking and payments
> systems, and that ripple should target underbanked users or markets
> where the commercial systems can't or won't go.
>
> Given that, I think the specific needs for atomicity needs to be clarified.
>
Atomicity reduces the risk for intermediaries participating in
transactions, and therefore drives down the fees they need to charge
to enable transactions.
> So the really important question is, what additional class users does
> atomicity include, as opposed to a non-atomic solution and would
> ripple compete with the commercial financial system for these users?
>
Intermediaries in the commercial financial system (ie, banks) would
probably be some of the last participants in Ripple, because it would
in all likelihood be a much less profitable system for them.
> I think that if a given use case requires a variety of pseudo-bank
> functions that these use cases might be best left to the commercial
> payments systems, or to a later version of distributed ripple.
>
Ripple is a system for enabling pseudo-bank functions at its core, so
that can't be avoided.
>> That's a strictly less effective solution than registries, I think,
>> since it still requires all transaction participants to trust a single
>> third party, but it requires them to trust it more strongly. The
>> implementation is also more complex.
>
> Well yes and no. Because the moving to a temporary host is a temporary
> arrangement for a single transaction while the annual fee based
> mechanism for paying registry fees is a much more extensive
> commitment.
>
What makes you think it's any easier to make a temporary arrangement
with a temporary host than to make a temporary arrangement with a
temporary registry?
Ryan
> The additional complexity of host-hopping is matched IMO by the
> whole-ecosystem complexity of the registries. Atomic transactions are
> going to be complex and somewhat costly whichever way they are
> implemented.
>
> Which brings me back to the chunking system. While this presents a
> possible danger to the payer (who may end up having transferred only
> part of the required payment), it makes things a lot easier and less
> risky for the intermediating nodes who reduce their worst case loss to
> a single chunk. I think that a key issue with ripple is incentivising
> intermediary nodes to participate, otherwise a transaction cannot even
> be initiated, and that therefore we should bias ripple to slightly
> favor intermediating nodes over the seller and buyer in order to
> maximise available liquidity, which IMO is ripple's unique selling
> point.
>
> Danny
>
Jorge Timón
One has to do with transactions with just a few intermediaries and the
other one consist in removing the authority role from the registers
with a privacy cost.
If we want to think in the intermediaries first.
The only atomicity an intermediary needs is the one needed for an
exchange of IOUs with the payer.
A node A1 (the payer) would say to A2:
Want to change A1 IOUs for A3 IOUs ?
Maybe he need to exchange A2 IOUs for the A3 with A3 before, but that
transaction (if atomic) would have no risk. He won't lose anything if
then he cannot make the trade proposed by A1.
If A2 can change A1->A2 IOUs for A2<-A3 IOUs atomicaly he doesn't care
about the rest of the transaction.
If A1 (the payer) cannot complete the whole transaction, and pay to
An, he would end up with IOUs to him from some stranger intermediary
Ak (3 < k < n).
It's up to the payer to try to make all of these mini-transactions or
none of them.
Maybe he requires a receipt from the seller in the last atomic transaction.
But for these exchanges of IOUs to be atomic the IOUs must be
transferable from node to node and it needs a system to prevent the
previous owner to spend the IOU (before the new owner).
You can require the sign of the original issuer of the IOU (not just
the last owner) to confirm that he is aware that he no longer owe to
the last owner.
Here's an exaple of atomic transfer of IOUs. The network has to be
A1<-A2<-A3 (A1 doesn't have a credit connection with A3 but, for some
reason, wants his IOUs).
SIGNER[ signed message ]
From A1 to A2: A1[ A1->A2, if A3->A1 ] = m1
From A2 to A3: A2[ A2->A3, if A3->A1 ] = m2 (In fact, this message
doesn't have to be signed)
From A3 to A2: A3[ A3->A1, if A2->A3 ] = m3
From A2 to A1 and A3: A2[ m1, m3 ] = m4
Now,
A1 can use m4 to pay to A3
A2 can use m4 to pay to A1
A3 can use m4 to pay to A2
I've just made up the symbols, we could use a different algebra.
If A1 is not interested in A3 as a seller but as a mere intermediary,
he's in a hurry to be able pay to An or he can end up with "useless"
IOUs from A3.
To make the set of micro-transactions of the whole transaction valid
at the same time, you have to add to every message signed by A1 a
condition that is only true when the whole transaction is commited.
That condition would be An[An->A1] or a receipt for the payment from A1 to An.
If we want these conditional IOUs to expire, time conditions can be
added to the messages before signing them (just like are added to the
promises for the registers to verify). If there's any time condition,
the last key to sign and thus the one that makes the commit effective
is the one of the timestamp server indicated by the condition sign.
The server do not need to know how to interpret the messages nor if a
message has expired or not: he just have to add the timestamp, sign
and send it back.
If different messages (or one) contain more than a time condition
(with the form {Server_ID, expiration timestamp}) with different
servers, then every server must sign the transaction.
Timestamp servers could then substitute the registers.
An easier way would be to just use two phase commit. The promises will
have time conditions and the transactions must have all the required
signed timestamps to be valid.
The payer would ask for all the signed timestamps. Just before doing
it he can calculate all the fees (including the timestamp server fees)
ad decide if he wants to make the transaction.
The payer would then pass the completed transaction to the seller
(An), who would pass it to An-1, etc
Every node would use the completed transaction as an IOU, since the
IOU they own have conditions that can only be demonstrated to be
satisfied showing the whole transactions
This springs privacy problems, but at least is not as public as the
block chain solution.
It has another problem The IOUs must be destroyed somewhere. If
they're destroyed conditionaly inside of a new transaction (instead of
issuing new ones), transaction messages can get very long (not to
mention the additional damage to privacy).
There has to be a limit in this recursive composition of transactions.
Therefore, they have to be destroyed elsewhere too (or only there).
Since the IOUs exist between credit neighbouring nodes, one can sign
the destruction of the transaction IOU while the other one issues a
new fresh and equivalent IOU.
They could use a third party to ensure the atomicity of this
transaction but given that they give themselves credit they probably
won't need it.
This is much like registries, but removing trusted the authority part.
Now every intermediary can run and trust his own timestamp server.
But there's a problem with both approaches. An intermediary can
require in his promises a third party that will always sign the
transaction with a time that is after the expiration time of his
promise.
I guess the network would find a way to exclude both the intermediary
and the third party for doing that.
It's an attack to consider.
2011/4/18, Ryan Fugger <a...@ryanfugger.com>:
Jorge Timón
If A2 can change A1->A2 IOUs for A2<-A3 IOUs atomicaly he doesn't care
about the rest of the transaction.
should be
A1->A2 IOUs for A2->A3
2011/4/18, Jorge Timón <timon....@gmail.com>:
danny jp
As you just pointed out to me, the existence of registries only
enables more participants and more payments. It can't by its nature
prevent any payments that would happen in a system without registries.
Agreed. The issue here is whether work on registries is worth it, and that we need to get to the bottom of why they might be needed, about which more below.
Atomicity reduces the risk for intermediaries participating in
>
transactions, and therefore drives down the fees they need to charge
to enable transactions.
I don't think it reduces risk much at all. This is because registries don't give any protection against default, just against a server outage. In the case of the latter, and without registries, if we assume there was no intent to defraud it would likely all be sorted out amicably and there might be some inconvencience but no losses. Registries don't protect against willful fraud, unless they have a reputational hold over all the participants.
Because nodes can be effectively anonymous, there is nothing to stop them defaulting to capture value and then using that value quickly and then abandoning the node and restarting elsewhere.
Therefore I think intermediaries are better protected in practice by chunking the transaction.
Intermediaries in the commercial financial system (ie, banks) would
> So the really important question is, what additional class users does
> atomicity include, as opposed to a non-atomic solution and would
> ripple compete with the commercial financial system for these users?
>
probably be some of the last participants in Ripple, because it would
in all likelihood be a much less profitable system for them.
My question was more along the lines of analyzing whether atomicity is required in the following situations (for example)
A) A person buying a basket of tomatoes for $2 from a gardener in his own village, via 3 intermediaries. Payment to follow delivery.
B) A person buying a beer in a bar at which he is not a regular for $4, via 5 intermediaries. Payment to precede consumption.
C) A person buying local private tuition for his kids for $200 via 4 intermediaries. Payment to follow delivery of service.
D) A person buying a rare book for $60 from a seller overseas via 9 intermediaries. Payment to precede delivery.
Ripple is a system for enabling pseudo-bank functions at its core, so
> I think that if a given use case requires a variety of pseudo-bank
> functions that these use cases might be best left to the commercial
> payments systems, or to a later version of distributed ripple.
>
that can't be avoided.
Its a system for distributed liquidity. What I meant by pseudo-bank functions is the notion of the 'trusted third party'. The original conception of ripple had only P2P bi-lateral (one to one) and bi-directional ('trust each other') trust connections and this was and is its great strength. With the registries you are introducing multilateral (e.g. many to one ) and unidirectional (trust not mutual) trust connections. This is effectively introducing bank type scenarios (e.g. many people trust the bank but the bank doesn't trust in return).
A server could be an instance of many-to-one and unidirectional trust, but the trust becomes bi-directional and mutual if the server trusts its users by granting credit for fees due. Also the critical difference between servers and registries is that one can easily move servers if one is not happy and still transact with no new restrictions, that is, one need only trust one server. Its harder to dump a registry if other users are still using it because then one would restrict the space of transactions that could be initiated. One is forced to trust multiple registries and eat the fees that result.
What makes you think it's any easier to make a temporary arrangement
with a temporary host than to make a temporary arrangement with a
temporary registry?
Because one need only trust one server at a time, as explained above.
Danny
Ryan Fugger
* promises conditional on a payer- and recipient-signed, and
optionally register-timestamped commit token being
timestamped/presented before a certain time, which cascade forward
down the payment chain,
you are proposing:
* promises conditional on all the other promises being collected in
one place and timestamped/presented before a certain time, which are
collected by the payer.
I'm not sure what is supposed to be gained by this though.
2011/4/17 Jorge Timón <timon....@gmail.com>:
> If we want these conditional IOUs to expire, time conditions can be
> added to the messages before signing them (just like are added to the
> promises for the registers to verify).
Registries don't know about promises and certainly don't verify them.
> If there's any time condition,
> the last key to sign and thus the one that makes the commit effective
> is the one of the timestamp server indicated by the condition sign.
> The server do not need to know how to interpret the messages nor if a
> message has expired or not: he just have to add the timestamp, sign
> and send it back.
> If different messages (or one) contain more than a time condition
> (with the form {Server_ID, expiration timestamp}) with different
> servers, then every server must sign the transaction.
>
> Timestamp servers could then substitute the registers.
Registries *are* nothing but timestamp servers.
Ryan
Ryan Fugger
>>
>> >
>> Atomicity reduces the risk for intermediaries participating in
>> transactions, and therefore drives down the fees they need to charge
>> to enable transactions.
>
> I don't think it reduces risk much at all. This is because registries don't
> give any protection against default, just against a server outage.
It is presumed in Ripple that holding one's neighbour's obligations
carries low enough risk to be willing to do so in order to
intermediate transactions for other users without charging an
overly-large transaction fee. Eliminating the risk involved with
server outage is important in this case.
> In the
> case of the latter, and without registries, if we assume there was no intent
> to defraud it would likely all be sorted out amicably and there might be
> some inconvencience but no losses.
Well, if my node holds a promise from your node, and I have a commit
that I want to use to redeem the promise, but couldn't communicate
with your node in time, because of some third-party router
misconfiguration, and you no longer hold a valid promise that you can
redeem with the commit, how are we supposed to work it out amicably so
no one suffers any losses?
Registries are just a mechanism for "sorting it out amicably".
> Registries don't protect against willful
> fraud, unless they have a reputational hold over all the participants.
>
It isn't my intent for Ripple to handle willful fraud between
neighbours. That's for a different system at a different level to
handle.
> Because nodes can be effectively anonymous, there is nothing to stop them
> defaulting to capture value and then using that value quickly and then
> abandoning the node and restarting elsewhere.
>
Nothing except people being careful about whom they trust, and any
legal agreements they might require from strangers before trusting
them.
> Therefore I think intermediaries are better protected in practice by
> chunking the transaction.
>
Chunking the transaction just moves most of the risk of loss due to
server outage from the intermediaries to the payer. It also opens an
attack on the payer where the recipient accepts half the payment
amount, and then refuses further promises on that transaction and any
further transactions from the payer. The recipient can honestly claim
to have only received partial payment, and say he is waiting for the
rest before delivering the goods being bought, knowing full well that
the rest of the payment can never come. It may be very difficult to
pin fault on the recipient for this, since he can claim that promises
are not reaching him due to insufficient credit, and may have even set
up a dummy node ahead of him to accomplish this insufficient credit.
The dummy node can also be used to show that he cannot send a refund
due to insufficient credit. Now the payer has to sue to get his money
back, but on quite shaky premises.
> My question was more along the lines of analyzing whether atomicity is
> required in the following situations (for example)
>
> A) A person buying a basket of tomatoes for $2 from a gardener in his own
> village, via 3 intermediaries. Payment to follow delivery.
> B) A person buying a beer in a bar at which he is not a regular for $4, via
> 5 intermediaries. Payment to precede consumption.
> C) A person buying local private tuition for his kids for $200 via 4
> intermediaries. Payment to follow delivery of service.
> D) A person buying a rare book for $60 from a seller overseas via 9
> intermediaries. Payment to precede delivery.
>
The requirement for atomicity has nothing to do with what is being
bought, by whom, for how much, for for what reason. It has to do with
the transaction system being robust and reliable for any payment.
> Its a system for distributed liquidity. What I meant by pseudo-bank
> functions is the notion of the 'trusted third party'. The original
> conception of ripple had only P2P bi-lateral (one to one) and bi-directional
> ('trust each other') trust connections and this was and is its great
> strength. With the registries you are introducing multilateral (e.g. many to
> one ) and unidirectional (trust not mutual) trust connections. This is
> effectively introducing bank type scenarios (e.g. many people trust the bank
> but the bank doesn't trust in return).
>
The type of trust you need to place in a registry *is not* the kind of
trust one places in a bank. You are not trusting the registry to make
sure its obligations have exchange value into the future! A registry
does not issue any financial obligations. It only testifies as to
whether or not it has had a particular commit message submitted to it
before a certain time. Nothing more or less. You are confusing two
very different kinds of trust relationships.
> A server could be an instance of many-to-one and unidirectional trust, but
> the trust becomes bi-directional and mutual if the server trusts its users
> by granting credit for fees due. Also the critical difference between
> servers and registries is that one can easily move servers if one is not
> happy and still transact with no new restrictions, that is, one need only
> trust one server. Its harder to dump a registry if other users are still
> using it because then one would restrict the space of transactions that
> could be initiated. One is forced to trust multiple registries and eat the
> fees that result.
>
It is actually very easy to dump a registry: publish contradictory
commits and non-commits that it has signed showing it has cheated.
I suppose there are other reasons to want to dump a registry, such as
it does not reliably respond to your requests, or it is too slow, or
too expensive. In most cases other servers will notice this too and
want to dump it around the same time. But if the poor service is
restricted to or targeted at your server for some reason, you would
have to dump it unilaterally, meaning that, if your nodes required
full atomicity, they would not be able to intermediate transactions
using that registry. In all likelihood there are still other common
registries you share with other servers you deal with, so nothing is
really lost except a bit of margin of safety in fallback registries
for you.
If for some reason your server is a pariah to *all* the common network
registries, then you will have to champion a friendly registry
(perhaps your own) to become widely accepted. If it is important
enough to you that you can support the friendly registry in offering
good terms to other servers (cheap/free service, good performance,
insurance against accidentally-issued contradictory
commits/non-commits) and make it easy for them to whitelist you, and
most other servers still wish to repudiate you, then either you have
done something quite offensive and wrong and deserve your treatment,
or there is a controlling cartel of Ripple servers that has decided to
exclude you from participation in the network for selfish reasons. In
either case, the problem isn't with the existence of registries in the
system.
>
>
>>
>> What makes you think it's any easier to make a temporary arrangement
>> with a temporary host than to make a temporary arrangement with a
>> temporary registry?
>
> Because one need only trust one server at a time, as explained above.
>
How's that different from deciding to only trust one registry at a time?
Ryan
Jorge Timón
proposal well.
> * promises conditional on a payer- and recipient-signed, and
> optionally register-timestamped commit token being
> timestamped/presented before a certain time, which cascade forward
> down the payment chain,
Let's see if I got it right this time.
Imagine all the participants agree in using one and the same registry.
The registry would timestamp once the whole transaction or one time
for every intermediary that has designated him as a registry?
Ryan Fugger
> Let's see if I got it right this time.
> Imagine all the participants agree in using one and the same registry.
> The registry would timestamp once the whole transaction or one time
> for every intermediary that has designated him as a registry?
>
Once for the whole transaction.
Ryan
danny jp
> that I want to use to redeem the promise, but couldn't communicate
> with your node in time, because of some third-party router
> misconfiguration, and you no longer hold a valid promise that you can
> redeem with the commit, how are we supposed to work it out amicably so
> no one suffers any losses?
Actually having now working it through in full detail, I see you're
right, atomicity is an issue. The weakness seems to stem from the fact
that when an intermediary choses to default, he is essentially
defaulting on the payer and not his trusted neighbours.
However, I still strongly stand by my concerns about constructing
unwieldy and formal many-to-one unilateral trust and payment links.
These structures are alien to the ripple concept.
So there is a conundrum here. However thinking on it it more I think a
practical approach along the lines of Jans host routing idea is the
most appropriate solution. If we assume this:
1) The payment path involves only a few servers.
2) the user nodes are generally congregating together on servers.
3) Servers offer to their user nodes that they will make good on
losses due to outages or bad behaviour.
then it can work like this:
1) each server is also a ripple node.
2) the payment path is constructed such that inter-server transfers
include the nodes of both servers in the path. e.g (Here A,B are on
server X, and C,D,E on server Y.
A pays B pays X pays Y pays C pays D pays E
If we assume that A to B is atomic and so is C to E, then the only
weak link is X to Y. A trusts X, and X promises to repay A if
anything goes wrong. X requires from Y a similar promise. Basically a
chain of 'insurance' promises extends from the payees server to the
payers server, in the opposite direction to the nodes promises, and
with the expectation that these would just expire. Now, if any server
doesn't play ball, it knows it will be hurting its trusted connected
servers, and not just the payers server which may be several
connections removed.
This justifies fees charged by X to A, and ultimately these fees cover
losses incurred by servers.
There is a multilateral many-to-one relationship here, which is trust
given to the server by its nodes. However I think this exists anyway,
given that at any moment a server could simply alter or delete its
clients credit links. As long as it was easy to move servers, and you
keep a personal backup of your link state signed by your connections I
think this is a more robust arrangement than the registry. Only
servers would need a credit score. This sounds to me like a simplified
form of trust-davis?
In a nutshell, I am saying that somewhere, to make all this work, a
many-to-one trust relationship is required, and that given that in
practice this will already exist in the form of highly populated
servers, we should aim to re-use this inherent trust relationship
rather than add another layer of third parties.
Naughty servers would be quickly excluded by other servers, and then
abandoned by their client nodes.
Seems too easy. Where is the flaw???
Ryan Fugger
> Actually having now working it through in full detail, I see you're
> right, atomicity is an issue. The weakness seems to stem from the fact
> that when an intermediary choses to default, he is essentially
> defaulting on the payer and not his trusted neighbours.
>
I don't understand what you mean by "default" here, and how an
intermediary could default on the payer, who isn't owed anything in a
transaction, but only owes.
> However, I still strongly stand by my concerns about constructing
> unwieldy and formal many-to-one unilateral trust and payment links.
> These structures are alien to the ripple concept.
>
As I said earlier, the trust in registries is very limited in nature
and easily demonstrated to be broken when it has been, so I have no
concerns about it. If by "unilateral payment links" you mean having
servers potentially sending periodic payments to registries, then I
fail to see how this is any different than anyone sending Ripple
payment to anyone else for any other good or service. Sure, it would
be better if we could achieve real-time atomicity without requiring
all transaction participants to trust a third-party timestamper, but I
can't think of how to do it.
> 1) The payment path involves only a few servers.
> 2) the user nodes are generally congregating together on servers.
> 3) Servers offer to their user nodes that they will make good on
> losses due to outages or bad behaviour.
>
I don't think any of these assumptions are appropriate here.
> then it can work like this:
>
> 1) each server is also a ripple node.
> 2) the payment path is constructed such that inter-server transfers
> include the nodes of both servers in the path. e.g (Here A,B are on
> server X, and C,D,E on server Y.
>
> A pays B pays X pays Y pays C pays D pays E
>
If cell-structure routing ever gets developed, it may treat
transactions something like this, or some variation on it.
> There is a multilateral many-to-one relationship here, which is trust
> given to the server by its nodes. However I think this exists anyway,
> given that at any moment a server could simply alter or delete its
> clients credit links.
Trust that your server will process data properly isn't the same as
trust that it will ensure obligations are valuable for exchange in the
future. One of the key strengths of Ripple is that, unlike the
banking system, it allows regular users to choose whom to trust for
each separately.
Ryan
> As long as it was easy to move servers, and you
> keep a personal backup of your link state signed by your connections I
> think this is a more robust arrangement than the registry. Only
> servers would need a credit score. This sounds to me like a simplified
> form of trust-davis?
>
> In a nutshell, I am saying that somewhere, to make all this work, a
> many-to-one trust relationship is required, and that given that in
> practice this will already exist in the form of highly populated
> servers, we should aim to re-use this inherent trust relationship
> rather than add another layer of third parties.
>
> Naughty servers would be quickly excluded by other servers, and then
> abandoned by their client nodes.
>
> Seems too easy. Where is the flaw???
>
danny jp
> intermediary could default on the payer, who isn't owed anything in a
> transaction, but only owes.
If payer A owes 10 to B who owes 10 to C and then C declines to pass
on the value up the chain, C effectively defaults on the payer because
the payee never gets paid and never ships the goods. The payee is owed
the goods.
It may be that the node prior to the payee (say 'E') decides to make
good on the promise anyway in which case the goods get shipped and
then C has defaulted on E.
danny jp
"The payer is owed the goods."
Ryan Fugger
That's why the recipient gets paid first by collecting on the last
intermediary's promise, then the last intermediary collects on the
previous intermediary's promise, and so on, back to the payer, who is
the last to pass forward an IOU.
Ryan
danny jp
Is it possible to have a solution in which each pair of nodes in the chain agree on their own trusted third party, rather than having all nodes agree to the same one? This would be a lot less onerous since its much more likely that I and my trusted connections have either a common node who could act in this capacity or that we use a common registry?
danny jp
Doh, what am I talking about? Too late at night!
Is it possible to have a solution in which each pair of nodes in the chain agree on their own trusted third party, rather than having all nodes agree to the same one? This would be a lot less onerous since its much more likely that I and my trusted connections have either a common node who could act in this capacity or that we use a common registry?
something like this http://research.microsoft.com/apps/pubs/default.aspx?id=64636
I guess this would create privacy issues but then doesn't the registry get to find out the ID of all the participating nodes in any case?
Ryan Fugger
> Is it possible to have a solution in which each pair of nodes in the chain
> agree on their own trusted third party, rather than having all nodes agree
> to the same one? This would be a lot less onerous since its much more likely
> that I and my trusted connections have either a common node who could act in
> this capacity or that we use a common registry?
>
Yes, that is the basic way registries operate, and was already in the
protocol as "arbiters". The desire to minimize risk, though, will
lead intermediaries to want to require the same registries on their
promises forward as they are offered on their promises held, and when
all nodes in the transaction do that, you get full atomicity. My
proposal was simply to enable that most efficiently.
> Perhaps the set of trusted third parties selected as per above can have some
> kind of consensus voting scheme to arbitrate who was responsible for any
> outage and what the rollback scheme is...
>
> something like this
> http://research.microsoft.com/apps/pubs/default.aspx?id=64636
>
Unfortunately, this requires all registries to cooperate
non-maliciously and have perfect communication, which we can't
presume. But if certain registries agreed to trust each other and
cooperate, then something like this might work.
It can be even simpler though. If two registries wish to cooperate so
that they effectively become "transaction compatible", they would only
need to agree to provide full services to each other's users (by, for
example, sharing a user database) and be accountable for those
services (by, for example, extending any SLAs or downtime insurance to
include the other registry's services as as well). Then all nodes who
accept one can accept the other, and it requires nothing extra in the
protocol.
Ryan
Jorge Timón
more the words "distributed timestamp server" come to mind.
Some bitcoiners are talking about bitx, a project to share a block
chain for different aplications, but I don't know if it's under
developement.
http://www.bitcoin.org/smf/index.php?topic=1790.0
I've been also thinking about your idea of having transaction chains
that can be merged. It seems feasible to me. I mean, not my proposal
with the binding advertisements and publication of every transaction,
but for the simple commit chain of yours. Then the limit for the
promises to expire would be a transaction number in the chain. The
payer just have to public a hash of the completed transaction for all
the intermediaries to verify.
2011/4/19, Ryan Fugger <a...@ryanfugger.com>:
danny jp
> protocol as "arbiters".
Is the write-up still there?
> Unfortunately, this requires all registries to cooperate
> non-maliciously and have perfect communication, which we can't
> presume. But if certain registries agreed to trust each other and
> cooperate, then something like this might work.
>
My reading of the paxos paper above and a quick scan of the related
literature suggests that is not the case, although I'll be the first
to admit I'm as likely wrong as right.
From this link:http://betathoughts.blogspot.com/2007/06/brief-history-of-consensus-2pc-and.html
"Eventually distributed transactions would be seen as a version of
consensus, called uniform consensus (see "Uniform consensus is harder
than consensus" (2000)). With uniform consensus all processes must
agree on a value, even the faulty ones - a transaction should only
commit if all RMs are prepared to commit. Most forms of consensus are
only concerned with having the non-faulty processes agree. Uniform
consensus is more difficult than general consensus."
From: http://en.wikipedia.org/wiki/Paxos_(computer_science)
"Paxos can tolerate lost messages, delayed messages, repeated
messages, and messages delivered out of order. It will reach consensus
if there is a single leader for long enough that the leader can talk
to a majority of processes twice. Any process, including leaders, can
fail and restart; in fact all processes can fail at the same time, the
algorithm is still safe. There can be more than one leader at a time."
And critically also from the wikipedia link above:
"Byzantine Paxos
Paxos may also be extended to support arbitrary failures of the
participants, including lying, fabrication of messages, collusion with
other participants, selective non-participation, etc. These types of
failures are called Byzantine failures, after the solution popularized
by Lamport.[15]
Byzantine Paxos[10][12] adds an extra message (Verify) which acts to
distribute knowledge and verify the actions of the other processors:"
I hear what you are saying about co-operation of registries to make
the system simpler, but if Byzantine Paxos is a viable solution then
users need not rely on such benign registry co-operation arising since
there would be a full solution in the protocol. Also, when any node
can take part as an arbiter, the liklihood is that you can select an
arbiter with whom you have a direct ripple connection in order to pass
them a micropayment. And then they would likely use you for their
transaction, enablnig you to zero your mutual balance.
Maybe you already looked at this particular class of protocols and
rejected them for a reason I don't understand yet?
Cheers,
Danny
Ryan Fugger
> I don't know. The more I think in the registers for time stamping, the
> more the words "distributed timestamp server" come to mind.
> Some bitcoiners are talking about bitx, a project to share a block
> chain for different aplications, but I don't know if it's under
> developement.
>
> http://www.bitcoin.org/smf/index.php?topic=1790.0
>
> I've been also thinking about your idea of having transaction chains
> that can be merged. It seems feasible to me. I mean, not my proposal
> with the binding advertisements and publication of every transaction,
> but for the simple commit chain of yours. Then the limit for the
> promises to expire would be a transaction number in the chain. The
> payer just have to public a hash of the completed transaction for all
> the intermediaries to verify.
>
The reason I favour regular monolithic registries over a bitcoin-style
block chain acting as a distributed registry is support for payments
being committed with 100% certainty in real-time. The block chain
only offers probabilistic commit over time. It wouldn't be hard to
add on to the protocol though, and I realize it would be useful for a
large class of transactions that don't need real-time certainty and
prefer a completely distributed solution. I'm currently re-writing
the protocol draft to be more modular so it is more clear how
alternative subsystems like this could be used.
Ryan
Ryan Fugger
Yes, it's the protocol v0.5 draft.
>> Unfortunately, this requires all registries to cooperate
>> non-maliciously and have perfect communication, which we can't
>> presume. But if certain registries agreed to trust each other and
>> cooperate, then something like this might work.
>>
>
> My reading of the paxos paper above and a quick scan of the related
> literature suggests that is not the case, although I'll be the first
> to admit I'm as likely wrong as right.
>
From the paper you linked to:
"The Paxos algorithm guarantees that at most one value is chosen de-
spite any non-malicious failure of any part of the system—that is, as long as
processes do not make errors in executing the algorithm and the communica-
tion network does not undetectably corrupt messages. It guarantees progress
if a unique leader is selected and if the network of nodes executing both that
leader and some majority of acceptors is nonfaulty for a long enough period
of time."
The key word is "non-malicious", meaning it the algorithm requires all
participating registries to trust each other not to be malicious. My
point is that if they trust each other like that, they might as well
just vouch for each other to their users so their users can trust them
too, and nothing needs to be added to the protocol to support this.
Ryan
danny jp
> participating registries to trust each other not to be malicious. My
> point is that if they trust each other like that, they might as well
> just vouch for each other to their users so their users can trust them
> too, and nothing needs to be added to the protocol to support this.
Agreed. But the extension to paxos called Byzantine Paxos as defined
danny jp
that message...
Jorge Timón
and therefore ripplecoins have to be issued.
On the other hand, with the mergeable commit chain, the incentive
problem get solved and the transactions are almost real time. Once you
spread your commit through the network, you don't have wait for the
transaction to be known by most of the computer power in the network
nor to the next block to arrive because in the commit chain you don't
have to prevent double spending.
I still don't know how merges of commit chains should be done
Imagine the las transaction shared b all peers is T1. At that moment,
two nodes use T1 to create TA2 and TB2 repectively.
Then A, and B chains grow in parallel for a while.
Then someone receives both chains and merges TA20 and TB8. What
happens now if someone creates TB9 before receiving TC21 (or
whatever)?
Maybe there's no problem with having parallel representations of the
same chain, since they will end up merged and there's no need to
preserve long parts of the chain.
Anyway, modularity is always welcomed. Even the public block chain
with binding advertisements had advantages: it allows an intermediary
to participate in transactions while being off-line. It also adds a
"centralized" clock needed for implementing interest or demurrage, for
example.
2011/4/19, Ryan Fugger <a...@ryanfugger.com>:
Ryan Fugger
> Agreed. But the extension to paxos called Byzantine Paxos as defined
> in the wikipedia link and which I quoted above says:
>
>
> "Byzantine Paxos
>
> Paxos may also be extended to support arbitrary failures of the
> participants, including lying, fabrication of messages, collusion with
> other participants, selective non-participation, etc. These types of
> failures are called Byzantine failures, after the solution popularized
> by Lamport.[15]
> Byzantine Paxos[10][12] adds an extra message (Verify) which acts to
> distribute knowledge and verify the actions of the other processors:""
>
OK, I read more closely, but I'm having trouble seeing how to apply
this to a Ripple transaction. First, if we can achieve reliable and
enforceable distributed consensus, then we don't need registries --
nodes themselves can just find consensus (privacy issues
notwithstanding), so let's consider that scenario since it involves
fewer actors.
The problem with the Paxos algorithm (even the Byzantine version) is
that it accepts the majority decision, and only works when a majority
of nodes aren't colluding maliciously. In Ripple, the payer can
always invent a string of dummy nodes to participate in the
transaction and have them collude in any decision-making process, so
Paxos can't work. For example, the payer could have his dummy nodes
issue a commit consensus decision to the recipient, and a rollback
consensus decision to the first non-payer node, meaning there would be
no actual consensus among real participants. This applies equally to
the case where each promise specifies a different registry, and the
registries need to achieve consensus: the payer can use dummy
registries on dummy accounts at the start of the chain to ensure he
has a majority.
Did you have something else in mind?
We might try to imagine a Paxos-type system that required a unanimous
vote from all the nodes to commit. But in a sense, that's what the
Ripple transaction system *is*: Promises are the payer's and
intermediaries' votes to commit, and signing the commit message is the
recipient's vote to commit, which can only happen once all promises
have been made, and so indicates unanimity. The problem is in
communicating this unanimity reliably to all nodes, while still
allowing for a mechanism for reliably aborting the transaction in a
timely fashion if there is no unanimity. Paxos does not address this
issue that I can see.
Ryan
Ryan Fugger
> With a bitcoin-style block chain, we still have the incentive problem
> and therefore ripplecoins have to be issued.
> On the other hand, with the mergeable commit chain, the incentive
> problem get solved and the transactions are almost real time. Once you
> spread your commit through the network, you don't have wait for the
> transaction to be known by most of the computer power in the network
> nor to the next block to arrive because in the commit chain you don't
> have to prevent double spending.
>
> I still don't know how merges of commit chains should be done
> Imagine the las transaction shared b all peers is T1. At that moment,
> two nodes use T1 to create TA2 and TB2 repectively.
> Then A, and B chains grow in parallel for a while.
> Then someone receives both chains and merges TA20 and TB8. What
> happens now if someone creates TB9 before receiving TC21 (or
> whatever)?
> Maybe there's no problem with having parallel representations of the
> same chain, since they will end up merged and there's no need to
> preserve long parts of the chain.
>
Actually, you point out a potential problem with the mergeable commit
chain: You can add a commit and make it appear to have been added at
an earlier time, because that situation isn't fundamentally
distinguishable from a simple communication delay that led to a
particular branch being slow to propagate and merge back with the
other branches. Not sure how to solve this. This problem throws a
wrench into things because nodes must be able to be certain that a
commit doesn't exist at a certain time in order to free up reserved
credit if the recipient hasn't issued a commit or promise-release.
Ryan
Ryan Fugger
>
> The problem with the Paxos algorithm (even the Byzantine version) is
> that it accepts the majority decision, and only works when a majority
> of nodes aren't colluding maliciously. In Ripple, the payer can
> always invent a string of dummy nodes to participate in the
> transaction and have them collude in any decision-making process, so
> Paxos can't work. For example, the payer could have his dummy nodes
> issue a commit consensus decision to the recipient, and a rollback
> consensus decision to the first non-payer node, meaning there would be
> no actual consensus among real participants. This applies equally to
> the case where each promise specifies a different registry, and the
> registries need to achieve consensus: the payer can use dummy
> registries on dummy accounts at the start of the chain to ensure he
> has a majority.
>
I do, however, see that majority voting requirement can make the
registry system more reliable where multiple registries are used on
the same promise. My initial proposal allowed for multiple registries
per promise, but required unanimity among them for commit, which can
cause credit tie-ups if one of them can't be reached, and the rest
vote for commit. (You'd have to wait to hear from the offline one to
determine whether it was really commit or rollback). If instead we
just required a majority for commit, then the system would be
resilient against failure of a minority of registries for a promise.
(For transaction atomicity, all promises would still need to have the
same set of registries.)
Ryan
danny jp
> OK, I read more closely, but I'm having trouble seeing how to apply
> this to a Ripple transaction. First, if we can achieve reliable and
> enforceable distributed consensus, then we don't need registries --
> nodes themselves can just find consensus (privacy issues
> notwithstanding), so let's consider that scenario since it involves
> fewer actors.
Registries don't provide enforceability either, they just provide a
strong proof, and even then only to protect against network
unavailability and any disputes arising thereof amongst basically
legitimate actors. I think you made this point quite clearly and
rightly earlier.
>
> The problem with the Paxos algorithm (even the Byzantine version) is
> that it accepts the majority decision, and only works when a majority
> of nodes aren't colluding maliciously.
Agreed, but see above.
In Ripple, the payer can
> always invent a string of dummy nodes to participate in the
> transaction and have them collude in any decision-making process, so
> Paxos can't work.
If I the payer have a string of dummy nodes which connects to a node
of the payee, and I defraud him then its his lookout because he
trusted my node. If OTOH there is a real node, belonging to neither me
or the payee in between us, then this is the chump who'll eat the
loss. However, once again he must have decided to trust my dummy node.
As you pointed out before, the ripple protocol can't and rightly
doesn't deal with malicious default. The registries as you set out
before are focused on protecting against server outage. If this is the
goal, then I suggest Byzantine paxos is a good choice to get consensus
on a transaction timestamp.
I am proposing that we retain your concept of timestamp servers but
derive a timestamp (the " proposed value" in the paxos literature)
using Byz.Paxos rather than requiring all participants to agree on one
registry, that's all.
> We might try to imagine a Paxos-type system that required a unanimous
> vote from all the nodes to commit.
I'm talking about BPax to generate an agreement on a timestamp as a
group, rather than having to all agree on one registry. The two phase
commit literature seems to designate a TM (transaction manager), which
is basically your registry. So using registries all users must achieve
consensus on the leader (TM) prior to starting. What BPax offers is
the ability to agree on a TM in a distributed fashion, using the BPax
algo. The Paxos paper from earlier proves that the paxos algo with one
TM reduces exactly to the classic two phase commit.
So using registries doesn't remove the need to gain consensus, it just
pushes the problem to a higher layer, which is fine from a protocol
perspective (as the protocol is currently defined) but it simply
defers the 'paxos' distributed consensus problem to be considered
bythe end users. Which is why I have been talking about these higher
layer solutions to consensus and their possible implications in this
thread. Because unless we come up with at least one plausible fleshed
out solution for the higher layer consensus issue the protocol could
turn out to be unusable in practice.
But in a sense, that's what the
> Ripple transaction system *is*: Promises are the payer's and
> intermediaries' votes to commit, and signing the commit message is the
> recipient's vote to commit, which can only happen once all promises
> have been made, and so indicates unanimity. The problem is in
> communicating this unanimity reliably to all nodes, while still
> allowing for a mechanism for reliably aborting the transaction in a
> timely fashion if there is no unanimity. Paxos does not address this
> issue that I can see.
Paxos can communicate this reliably to all nodes. If there was a
server outage, then afterwards the affected node would query all the
participating arbiter nodes (I think these are called "acceptors" in
paxos parlance), to see what the consensus decision was about the
timestamp. Because a majority consensus is obtained prior to the
commit, that is as good as unanimity since even those nodes not
becoming part of that consensus can chose to commit anyway (since
likely all they care about is that there is a valid timestamp that
could be used later in the event of an outage during the final part of
the transaction) as long as they are sure a viable majority decision
is established.
Obviously this requires that the acceptors/arbiters all have to
communicate between themselves.
A quick reading of the papers suggests that something like 'Fast
Byzantine Paxos' will complete in the non-faulty case almost as
quickly as a classic two phase commit, with material delays coming
into it in the faulty case only.
It also has the advantage of dealing with the problem of an
unresponsive registry that you mentioned in relation to the single
registry solution.
So in summary I am not proposing paxos to perform credit checking and
enforcement functions, just to provide a transaction timestamp. I feel
this is important since then distributed ripple is a democracy of
servers, whereas with registries it could become a tyranny of
registries. You might feel that's a bit strong, but the privileged
position of registries allows them to capture the ripple market.
Because they would have to be paid fees and users would need accounts
with them, they then have a competitive advantage to offer credit
scoring, hosting and other services.
To then suggest that this would be solved by competition between
registries merely suggests a proliferation of registries, with
registries springing up and going out of business all the time, in
which case the distributed consensus achievement problem, which has
been pushed up the solutions stack, has still not been solved, from
the perspective of real users, who we need to think about even at this
design stage.
All that said, in the real world, I think that credit scoring is going
to be desired by real users, so even if we dealt with the issue of a
genuinely distributed solution to transaction commit, we shall soon
come up against the design problem of genuinely distributed credit
scoring, but I agree that credit scoring is a matter for another
protocol.
Ryan Fugger
> Registries don't provide enforceability either, they just provide a
> strong proof, and even then only to protect against network
> unavailability and any disputes arising thereof amongst basically
> legitimate actors. I think you made this point quite clearly and
> rightly earlier.
>
They most certainly do provide enforceability of the commit decision
to pass IOUs forward. I can take my signed promise and
registry-timestamped commit token before a judge and his decision will
be in my favour, because my adversary (my neighbour) cannot provide a
registry-timestamped rollback token.
The enforceability of IOUs, of course, is outside the scope of the protocol.
>>
>> The problem with the Paxos algorithm (even the Byzantine version) is
>> that it accepts the majority decision, and only works when a majority
>> of nodes aren't colluding maliciously.
>
> Agreed, but see above.
>
> In Ripple, the payer can
>> always invent a string of dummy nodes to participate in the
>> transaction and have them collude in any decision-making process, so
>> Paxos can't work.
>
> If I the payer have a string of dummy nodes which connects to a node
> of the payee, and I defraud him then its his lookout because he
> trusted my node. If OTOH there is a real node, belonging to neither me
> or the payee in between us, then this is the chump who'll eat the
> loss. However, once again he must have decided to trust my dummy node.
>
No, all the dummies go before the payer's real node:
D1 -> D2 -> D3 -> D4 -> P -> I1 -> I2 -> R
Dx are dummies, P is payer's real node, Ix are intermediaries, R is
recipient. Payer can now create both commit and rollback tokens using
his majority in the payment chain. (If we're using registries, he
specifies dummy registries on the dummy accounts.) So he passes a
commit token to R and I2 and a rollback token to I1 simultaneously.
Now I1 and I2 have to fight it out for who pays for P's profit.
Ryan
danny jp
> to pass IOUs forward. I can take my signed promise and
> registry-timestamped commit token before a judge and his decision will
> be in my favour, because my adversary (my neighbour) cannot provide a
> registry-timestamped rollback token.
No I don't think you can. Firstly, no asset has been transferred at
any point in the whole transaction. You could go to the judge and say,
hey this guy owes me 30 bucks. But he'd say, no you didn't, where are
the 30 physical bucks you are talking about? In contrast, when you get
a loan from a commercial bank, the $30 is transferred to you after you
sign on the line.
Secondly, to be enforceable as you suggest the entire transaction
would have to be covered by a legal contract which would have to be
autogenerated and signed and witnessed by all parties prior to
initiating the transaction. At this point, ripple would attract the
full regulatory force of the law, requiring credit agreements, cooling
off periods and so on.
>
> The enforceability of IOUs, of course, is outside the scope of the protocol.
Ripple never trades anything but IOUs.
> No, all the dummies go before the payer's real node:
>
> D1 -> D2 -> D3 -> D4 -> P -> I1 -> I2 -> R
>
> Dx are dummies, P is payer's real node, Ix are intermediaries, R is
> recipient. Payer can now create both commit and rollback tokens using
> his majority in the payment chain. (If we're using registries, he
> specifies dummy registries on the dummy accounts.) So he passes a
> commit token to R and I2 and a rollback token to I1 simultaneously.
> Now I1 and I2 have to fight it out for who pays for P's profit.
That's still a case of malicious default in which P defaults on his
trusted connection I1. This is as you said before beyond the scope of
both registries and paxos based atomicity.
The same danger presents itself with registries, P simply refuses to
pass on any value, and the commit token is useless in either case
since it can't be enforced in law.
Danny
Ryan Fugger
The key thing is that I1 be able to prove that P is defecting on the
trusted connection, as opposed to the situation where P is defecting,
but can claim not to be, and I1 cannot tell. That is what I mean by
"enforceability".
Ryan
> Danny
danny jp
> trusted connection, as opposed to the situation where P is defecting,
> but can claim not to be, and I1 cannot tell. That is what I mean by
> "enforceability".
It seems we are now talking about more than server outages, and have
extended the scope of transaction atomicity to guard against fraud of
trusted connections as well. Is that correct?
If that is the case, then while what you have said above is correct I
think wrt paxos, from the perspective of user I1, then the proof he
might hold is of no use to him unless the proof can compel P, perhaps
by exposing his identify and malfeasance to the community. If L1 does
not know P's real world identity, then there is nothing he can do
whether his proof came from a registry or from the paxos scheme. If L1
does know Ps real identify, then there is also nothing he can do about
it unless there is a means of publicly blacklisting P on a distributed
reputation system. But even if such a system existed, if P is of
higher general standing than I1, then even that may not be much use.
That is why I said that this registry function would be become
conflated with reputation scoring. I withdrew that line of discussion
after understanding that we were just talking about network outages
and not about trusted connection fraud, but would now like to
re-instate it wrt transaction atomicity in general.
Sorry to go round in a big circle, but I think these issues of
reputation are crucial to consider now, even at this early stage for
the reasons I have given above. For example, do you expect most ripple
transactions to be done with anonymous nodes? The answer makes a huge
difference to the system design and to its possible use cases.
Ryan Fugger
>> The key thing is that I1 be able to prove that P is defecting on the
>> trusted connection, as opposed to the situation where P is defecting,
>> but can claim not to be, and I1 cannot tell. That is what I mean by
>> "enforceability".
>
>
> It seems we are now talking about more than server outages, and have
> extended the scope of transaction atomicity to guard against fraud of
> trusted connections as well. Is that correct?
>
Yes. When I have talked about "server outages" I have generally meant
to include malicious outages for the purposes of fraud. Sorry if that
wasn't clear.
> If that is the case, then while what you have said above is correct I
> think wrt paxos, from the perspective of user I1, then the proof he
> might hold is of no use to him unless the proof can compel P, perhaps
> by exposing his identify and malfeasance to the community. If L1 does
> not know P's real world identity, then there is nothing he can do
> whether his proof came from a registry or from the paxos scheme. If L1
> does know Ps real identify, then there is also nothing he can do about
> it unless there is a means of publicly blacklisting P on a distributed
> reputation system. But even if such a system existed, if P is of
> higher general standing than I1, then even that may not be much use.
>
If I1 has a legal agreement with P, registries allow him to enforce it
reliably, paxos doesn't.
Ryan
> That is why I said that this registry function would be become
> conflated with reputation scoring. I withdrew that line of discussion
> after understanding that we were just talking about network outages
> and not about trusted connection fraud, but would now like to
> re-instate it wrt transaction atomicity in general.
>
> Sorry to go round in a big circle, but I think these issues of
> reputation are crucial to consider now, even at this early stage for
> the reasons I have given above. For example, do you expect most ripple
> transactions to be done with anonymous nodes? The answer makes a huge
> difference to the system design and to its possible use cases.
>
Ryan Fugger
> I do, however, see that majority voting requirement can make the
> registry system more reliable where multiple registries are used on
> the same promise. My initial proposal allowed for multiple registries
> per promise, but required unanimity among them for commit, which can
> cause credit tie-ups if one of them can't be reached, and the rest
> vote for commit. (You'd have to wait to hear from the offline one to
> determine whether it was really commit or rollback). If instead we
> just required a majority for commit, then the system would be
> resilient against failure of a minority of registries for a promise.
>
Actually, I'm remembering why I rejected the majority vote for
commit/rollback in the first place. There is still the possibility of
half the registries voting commit, half voting rollback, and the last
deciding vote being offline, meaning the system still isn't resilient
to offline registries. The majority system is the most resilient of
the three (unanimous for commit, unanimous for rollback, majority for
commit), assuming the recipient sends a consistent decision to all
registries. But if the recipient wants to maliciously tie up credit,
and can collude with one of the registries, then none of these systems
is safe.
To protect against being manipulated like this, registries might use a
Paxos-type consensus system among themselves to attempt to come to a
consistent decision for commit or rollback together. I've also
realized that if registries are specified on a promise, their
signatures must be *required* and not optional on both commit and
rollback messages, since making them optional allows for opposing
decisions to be presented, one with registry signature and without.
Here's a sketch of a registry consensus protocol for when multiple
registries are specified on a promise:
1. The commit/rollback (decision) message would need to specify the
required registries on it, to prevent a malicious recipient from
circumventing the registry consensus process. A decision not
specifying the same registries in the same order as the promise is not
considered valid.
2. The recipient (or any intermediary) sends a decision token to one
or more of the registries.
3. When a registry receives a decision from a node, and does not know
a current leader, or has a decision that could override the current
leader's proposed decision, it sends a signed proposal to be leader to
the other registries in the list.
4. When a registry receives a leader proposal from another registry,
it accepts the proposal if it has not yet received a leader proposal
from another registry that is before the proposed leader in the list.
Otherwise it rejects the leader proposal.
5. When a registry receives majority acceptance of its leader
proposal, it issues an accept request to all registries, asking that
they accept its proposed decision.
6. When a registry receives an accept request, it accepts the
decision, if it comes from registry it thinks is the current leader,
by signing the decision token and passing it back to the leader. Once
accepted, a registry cannot change its decision.
This system is not immune to manipulation. A majority of registries
can collude to ensure that no decision emerges by refusing to answer
any requests. But it makes it more difficult for a malicious
recipient who controls a minority of registries to stymie a decision,
since it must attempt some kind of timing attack in order to get a
split decision from the honest majority of registries by getting some
of them to switch leaders after others have already accepted a
decision. This can be made even more difficult if registries insert a
small randomized delay before requesting to be leader if they are not
first in the list.
This is all too much for the first implementation I think, but I find
it reassuring to know that it can theoretically be made quite
resilient to failure and attack.
Ryan
Jorge Timón
> chain: You can add a commit and make it appear to have been added at
> an earlier time, because that situation isn't fundamentally
> distinguishable from a simple communication delay that led to a
> particular branch being slow to propagate and merge back with the
> other branches. Not sure how to solve this. This problem throws a
> wrench into things because nodes must be able to be certain that a
> commit doesn't exist at a certain time in order to free up reserved
> credit if the recipient hasn't issued a commit or promise-release.
True.
We cannot allow merge, because the payer could always cheat the timestamp.
But the transactions that are lost for this reason can still be
included in the longest chain on time.
In bitcoin, when a miner receives an orphan block (a block that cannot
be included in the longest chain because another one has occupied his
block number in it), he includes all the valid transactions (that are
not included in the block chain already) in the block he is trying to
solve.
When a ripple payer receives an orphan block, he can include it in his
own (if the promises have not expired with the next block number) and
add the proof of work that it contains to the the one he's
calculating.
The blocks can have different proofs (some stronger, some weakest)
because we don't need to stick to the average of 10 minutes per block
generated.
The payer must decide how must work he spends, knowing that the more
work he spends, the more likely to appear in the longest chain
quickly.
The reason behind the 10 minutes is to prevent forks in the block
chain, but since we don't lose too much when a the two forks "fight
between them to death", we don't have to avoid forks. No one losses 50
btc plus fees here and there's no double spending.
The time for confirmation here is just the time to know for sure that
there cannot be forks of the chain that born before your transaction.
The expiration times for the promises would be block numbers. To
enable the intermediary to calculate the expiration block number from
some time unit, we still can adjust a difficulty to get some average
time for block generation, but it doesn't have to be near the 10
minutes.
I would prefer not to rule the difficulty at all and let the
intermediaries adapt to the speed of block creation.
The problem is that now the intermediary have to wait two times.
First, to the expiration block. If the transaction is not commited
then, he knows his promise has expired.
Then, some time to see if he receives a longer chain that invalidates
the transaction. I lack the data networks and cryptography knowledge
to do the map.
If the proof of work is not ruled, the math would depend also in the
blocks you have in your block chain.
I know, maybe instant transactions still require third parties, but I
prefer it, because it allows the rest of the transactions to occur
without them.
Note that this is not incompatible with the registries and, like them,
is optional.
2011/4/20, Ryan Fugger <a...@ryanfugger.com>:
Ryan Fugger
>> Actually, you point out a potential problem with the mergeable commit
>> chain: You can add a commit and make it appear to have been added at
>> an earlier time, because that situation isn't fundamentally
>> distinguishable from a simple communication delay that led to a
>> particular branch being slow to propagate and merge back with the
>> other branches. Not sure how to solve this. This problem throws a
>> wrench into things because nodes must be able to be certain that a
>> commit doesn't exist at a certain time in order to free up reserved
>> credit if the recipient hasn't issued a commit or promise-release.
>
> True.
> We cannot allow merge, because the payer could always cheat the timestamp.
> But the transactions that are lost for this reason can still be
> included in the longest chain on time.
> In bitcoin, when a miner receives an orphan block (a block that cannot
> be included in the longest chain because another one has occupied his
> block number in it), he includes all the valid transactions (that are
> not included in the block chain already) in the block he is trying to
> solve.
> When a ripple payer receives an orphan block, he can include it in his
> own (if the promises have not expired with the next block number) and
> add the proof of work that it contains to the the one he's
> calculating.
Right, but with no merge, we're back to the problem of what motivates
someone to include a commit that's not theirs in their block.
> The problem is that now the intermediary have to wait two times.
> First, to the expiration block. If the transaction is not commited
> then, he knows his promise has expired.
You'd also want to allow rollback messages to be included in the block
chain to avoid this wait.
Ryan
Jorge Timón
>> own (if the promises have not expired with the next block number) and
>> add the proof of work that it contains to the the one he's
>> calculating.
>
> Right, but with no merge, we're back to the problem of what motivates
> someone to include a commit that's not theirs in their block.
There's no mining, only payers create blocks. But if If apyer includes
an orphan block in his own, he adds the work of the orphan block to
the work he's doing. Remember that the longest chain is the one with
the more proof of work.
"The client accepts the 'longest' chain of blocks as valid. The
'length' of the entire block chain refers to the chain with the most
combined difficulty, not the one with the most blocks. This prevents
someone from forking the chain and creating a large number of
low-difficulty blocks, and having it accepted by the network as
'longest'."
From here:
https://en.bitcoin.it/wiki/Blocks
>> The problem is that now the intermediary have to wait two times.
>> First, to the expiration block. If the transaction is not commited
>> then, he knows his promise has expired.
>
> You'd also want to allow rollback messages to be included in the block
> chain to avoid this wait.
If you allow rollback, you have to be aware of "double spending" again
and you have to be more cautious with the forks. Then, you may need
some fix rate for generating blocks again.
Furthermore, in this case, the mini-block with more work (the commit
or the rollback) will win even if the other one was sent previously,
because the incentive to include it is greater. With a similar work,
nodes would accept the one they have receive first.
Is the rollback really necessary?
Ryan Fugger
> There's no mining, only payers create blocks. But if If apyer includes
> an orphan block in his own, he adds the work of the orphan block to
> the work he's doing. Remember that the longest chain is the one with
> the more proof of work.
>
Ah, OK. So you can still include an orphan block's work in your own
block, but its old timestamp is ignored in favour of the one on your
block. I think that works.
> If you allow rollback, you have to be aware of "double spending" again
> and you have to be more cautious with the forks. Then, you may need
> some fix rate for generating blocks again.
You always have to be careful of this even without a rollback message.
The longest chain might eventually exclude your commit for the period
of promise validity, which is equivalent to a rollback.
> Is the rollback really necessary?
Yes. If the block chain is the commit authority, then it must also be
the rollback authority. If the recipient could unilaterally issue a
promise-release on a promise whose commit authority was the block
chain, it could also submit a commit to the block chain, giving two
contradictory commit decisions. The block chain's decision must
supercede the recipient's, so basically the promisor has to wait for
the block chain regardless of what it hears from the recipient. The
recipient needs a way to release promises before they expire, to avoid
tying up credit unnecessarily, so it must be able to submit a rollback
to the block chain.
So both commit and rollback will require waiting for the block chain
to cement either decision over time.
Ryan
danny jp
> to include malicious outages for the purposes of fraud. Sorry if that
> wasn't clear.
OK understood, thanks. I had thought you were restricting the
discussion to avoid incorporating default on trusted connections.
> If I1 has a legal agreement with P, registries allow him to enforce it
> reliably, paxos doesn't.
That's an interesting statement. It implies to me you are envisaging
this protocol draft to go significantly beyond the informal economy.
Some time ago (quite some while back) you indicated in a thread that
the informal economy was the target for current work. Have you revised
that thinking since?
The reason I ask, is that two nodes who have a legal agreement doesn't
fit my definition of a trusted connection.
Assuming you are targeting non-trust ripple (which I'll term gripple
for want of a better term, since nodes grip to each other with legal
force), then the registry protocol would need to have hooks in it to
make sure it could auto generate a legal contract that embeds the
timestamp in its wording otherwise it wouldn't hold up in court, even
assuming you can have a financial contract which doesn't involve asset
exchange.
In the case of a 'gentlemans agreement' which is how I envisaged the
ripple trust connections, then I don't need a proof of malfeasance, I
(as node I1) just need to point out to node P that he's not playing
cricket.
Going back to the gripple scenario, if we assumed that some
participants in the chain have gripple connections, and some have
ripple connections, does the registry protocol allow for those nodes
with ripple connections to opt out of the transaction registry leaving
the fees to accrue to just the gripplers?
Danny
Ryan Fugger
>> If I1 has a legal agreement with P, registries allow him to enforce it
>> reliably, paxos doesn't.
>
> That's an interesting statement. It implies to me you are envisaging
> this protocol draft to go significantly beyond the informal economy.
> Some time ago (quite some while back) you indicated in a thread that
> the informal economy was the target for current work. Have you revised
> that thinking since?
>
No. But supporting strong agreements is also very important.
Regardless, even if you have an informal arrangement, it is still very
important to be able to prove bad behaviour, rather than just suspect.
"Trust, but verify" -- much more robust that just "trust".
> The reason I ask, is that two nodes who have a legal agreement doesn't
> fit my definition of a trusted connection.
>
The legal system is just one way to establish trust.
Ryan
> Assuming you are targeting non-trust ripple (which I'll term gripple
> for want of a better term, since nodes grip to each other with legal
> force), then the registry protocol would need to have hooks in it to
> make sure it could auto generate a legal contract that embeds the
> timestamp in its wording otherwise it wouldn't hold up in court, even
> assuming you can have a financial contract which doesn't involve asset
> exchange.
>
> In the case of a 'gentlemans agreement' which is how I envisaged the
> ripple trust connections, then I don't need a proof of malfeasance, I
> (as node I1) just need to point out to node P that he's not playing
> cricket.
>
> Going back to the gripple scenario, if we assumed that some
> participants in the chain have gripple connections, and some have
> ripple connections, does the registry protocol allow for those nodes
> with ripple connections to opt out of the transaction registry leaving
> the fees to accrue to just the gripplers?
>
> Danny
>
danny jp
I only see three levels of strength that are possible:
A) a trust connection, a gentleman's agreement between two people,
anonymous to the rest of the system.
B) a gentleman's agreement backed up by informal community peer review
in which participants are not anonymous.
C) a legal agreement in which participants are not anonymous.
The registry protocol needs to be supplemented by hooks for credit
scoring and identity to satisfy B, and by generation of contracts to
satisfy C. The registry doesn't add anything to A, unless its purpose
is to simply unambiguously resolve benign server failure.
That's why I asked whether the registry proposal can cope with all
three of these kinds of relationships in a single commit chain.
> Regardless, even if you have an informal arrangement, it is still very
> important to be able to prove bad behaviour, rather than just suspect.
> "Trust, but verify" -- much more robust that just "trust".
I've argued that Byz.Paxos is sufficient for that - verification
between friends. Legal agreements don't imply verification of
gentleman's agreements , they imply binding to a contract to avoid the
need for full trust.
> The legal system is just one way to establish trust.
Use of the legal system doesn't imply trust between two parties. Both
parties trust the legal system but neither trusts the other.
As above, I can only see three levels of trust, unconditional,
reputational, and legal.
danny jp
scoring and identity to satisfy B"
Actually that may be wrong. The registry protocol would require a
higher layer for credit scoring and identity to satisfy B.
Right now I'm not sure whether that requires extra hooks in the proposal or not.
Danny
Jorge Timón
> block, but its old timestamp is ignored in favour of the one on your
> block. I think that works.
Yes, that's it.
>> If you allow rollback, you have to be aware of "double spending" again
>> and you have to be more cautious with the forks. Then, you may need
>> some fix rate for generating blocks again.
>
> You always have to be careful of this even without a rollback message.
> The longest chain might eventually exclude your commit for the period
> of promise validity, which is equivalent to a rollback.
But the forks are more dangerous if the possibility of conflicting
messages exist.
Without that possibility, there's nothing lost with the shortest
branch. Some commits will not be valid because they haven't been
included in the longest chain before the expiry times, but nothing
else will be lost.
With conflicting messages, the one in the longest chain wins.
In bitcoin, when two conflicting messages arrive to the same node, the
node will include the message that he received first. No one will gain
anything by not doing this.
But when the work of the orphan blocks can be used, the node that
receives both messages has an incentive to include the one with more
work.
If an intermediary sends a rollback, the payer just have to solve the
commit block with more work to ensure the commit. Even after a
rollback.
>> Is the rollback really necessary?
>
> Yes. If the block chain is the commit authority, then it must also be
> the rollback authority. If the recipient could unilaterally issue a
> promise-release on a promise whose commit authority was the block
> chain, it could also submit a commit to the block chain, giving two
> contradictory commit decisions. The block chain's decision must
> supercede the recipient's, so basically the promisor has to wait for
> the block chain regardless of what it hears from the recipient. The
> recipient needs a way to release promises before they expire, to avoid
> tying up credit unnecessarily, so it must be able to submit a rollback
> to the block chain.
>
> So both commit and rollback will require waiting for the block chain
> to cement either decision over time.
What I ment was, is a rollback authority necessary?
Can the intermediaries just live with the expiry block number for
their promises?
After all, They have to sign the transaction again after the payee
signs it, right?
Jorge Timón
ripple connections, I don't see any reason why bigger business can't
have connections between them based on legal agreements.
You could create a service for rating nodes and make connections to
them more attractive. I could create a service in which my clients
legally sign that the public key X belongs to them and the IOUs their
ripple node issues are legal IOUs and they can be sued if they don't
pay them. Giving credit to those nodes becomes more attractive too.
While explaining ripple to my friends many of them insist in the risk
of default. No matter how much times I tell them that the only people
who can cheat them are supposed to be their friends.
Many small businesses won't try ripple if they cannot go to court if
something goes wrong.
Verify is important even between friends. There's no argument if they
can know easily and unequivocally what happened.
2011/4/20, Jorge Timón <timon....@gmail.com>:
Ryan Fugger
> But the forks are more dangerous if the possibility of conflicting
> messages exist.
> Without that possibility, there's nothing lost with the shortest
> branch. Some commits will not be valid because they haven't been
> included in the longest chain before the expiry times, but nothing
> else will be lost.
> With conflicting messages, the one in the longest chain wins.
> In bitcoin, when two conflicting messages arrive to the same node, the
> node will include the message that he received first. No one will gain
> anything by not doing this.
> But when the work of the orphan blocks can be used, the node that
> receives both messages has an incentive to include the one with more
> work.
> If an intermediary sends a rollback, the payer just have to solve the
> commit block with more work to ensure the commit. Even after a
> rollback.
>
Only the recipient can generate the commit. (The current draft
requires the payer's signature as well, but that's a holdover from a
previous version that is probably no longer necessary. Even if it is,
the payer signs the commit and hands it to the recipient, who gets
final call.)
Intermediaries must wait for a rollback, or for the promise to expire
with no commit.
> What I ment was, is a rollback authority necessary?
> Can the intermediaries just live with the expiry block number for
> their promises?
Sure, but this ties up credit unnecessarily and will reduce the number
of possible transactions for no good reason.
Ryan
danny jp
> ripple connections, I don't see any reason why bigger business can't
> have connections between them based on legal agreements.
I have pointed out a few issues on this front in this thread both
generally and in the commit protocol specifically. However I agree
that business participation is important. Having raised these points
it now seems incumbent upon me to provide some answers rather than
more questions, so I've contacted the UK law making body about this
issue. I'll let you all know what I find out.
There is another way for business to participate in ripple, and that
is to have special ripple nodes who are licensed for mainstream
financial payments and have on one side ripple connections with
credits and debts and on the other mainstream payment connections to
businesses and banks. Then the outside world can buy and sell from/to
ripple nodes via these intermediaries.
No matter how much times I tell them that the only people
> who can cheat them are supposed to be their friends.
> Many small businesses won't try ripple if they cannot go to court if
> something goes wrong.
We should start a thread that gathers these anecdotal objections from
new people introduced to the ripple concept so we can fine tune the
presentations and other ripple marketing stuff.
>
> Verify is important even between friends. There's no argument if they
> can know easily and unequivocally what happened.
>
I agree, as long as the complexity and expense of the verif can be
tailored on an account by account basis rather than having a highest
common denominator.
Danny
Jorge Timón
>> commit block with more work to ensure the commit. Even after a
>> rollback.
>>
>
> Only the recipient can generate the commit. (The current draft
> requires the payer's signature as well, but that's a holdover from a
> previous version that is probably no longer necessary. Even if it is,
> the payer signs the commit and hands it to the recipient, who gets
> final call.)
I though the last to sign was the payer. When can he decide then, that
the fees are too high and rollback the payment?
If the transaction requires CPU work, I'm not sure who should be
required to do it, if the payer or the recipient.
As always, "CPU for your commit" services could emerge if the payer
uses, for example, a smartphone (one without dual core).
I think both of them should be able to do it.
> Intermediaries must wait for a rollback, or for the promise to expire
> with no commit.
>> What I ment was, is a rollback authority necessary?
>> Can the intermediaries just live with the expiry block number for
>> their promises?
>
> Sure, but this ties up credit unnecessarily and will reduce the number
> of possible transactions for no good reason.
Ok, having rollback has advantages. But in this case, if the work of a
"mini-block" can be used to calculate the total work for a block, the
the one that spends more CPU in the transaction wins. It doesn't
matter what message was sent first.
An attacker with enough CPU power, could start transactions commit
them and then rollback them with highly difficult proof. Than would
lock the credit of the intermediaries too.
On the other hand, if there's no rollback, it would be harder for the
attacker. To rollback transactions he needs to build a longer branch
and win the chain race. If the promises have not expired, the commit
is likely to appear in the chain again and the attacker would have to
build a parallel stronger branch again.
Since the block chain and the registries are different issues, I think
I'm going to start another thread.
Jorge Timón
>> Although existing trust between people is the primary target for
>> ripple connections, I don't see any reason why bigger business can't
>> have connections between them based on legal agreements.
>
> I have pointed out a few issues on this front in this thread both
> generally and in the commit protocol specifically. However I agree
> that business participation is important. Having raised these points
> it now seems incumbent upon me to provide some answers rather than
> more questions, so I've contacted the UK law making body about this
> issue. I'll let you all know what I find out.
>
> There is another way for business to participate in ripple, and that
> is to have special ripple nodes who are licensed for mainstream
> financial payments and have on one side ripple connections with
> credits and debts and on the other mainstream payment connections to
> businesses and banks. Then the outside world can buy and sell from/to
> ripple nodes via these intermediaries.
True. But I don't think I can create a service involving banks (maybe paypal).
In the other hand, a service to bind the signs of a ripple node with
the electronic signs from an electornic ID card seems easy to develop.
http://en.wikipedia.org/wiki/Electronic_identity_card
> No matter how much times I tell them that the only people
>> who can cheat them are supposed to be their friends.
>> Many small businesses won't try ripple if they cannot go to court if
>> something goes wrong.
>
> We should start a thread that gathers these anecdotal objections from
> new people introduced to the ripple concept so we can fine tune the
> presentations and other ripple marketing stuff.
Yes, that would be funny and useful.
>>
>> Verify is important even between friends. There's no argument if they
>> can know easily and unequivocally what happened.
>>
>
> I agree, as long as the complexity and expense of the verif can be
> tailored on an account by account basis rather than having a highest
> common denominator.
I would prefer ripple to be fully p2p too. There's nothing wrong with
the registries, I just don't like them much.
dann...@gmail.com
Sent from my BlackBerry® wireless device
danny jp
> the electronic signs from an electornic ID card seems easy to develop.
>
> http://en.wikipedia.org/wiki/Electronic_identity_card
Indeed, or OpenID.
> I would prefer ripple to be fully p2p too.
As would we all. Pure P2P does come at a price though as we are discovering.
Danny
Ryan Fugger
> I though the last to sign was the payer. When can he decide then, that
> the fees are too high and rollback the payment?
The payer specifies the path fully in advance, including all exchange
rates and fees. It's all in the draft.
> If the transaction requires CPU work, I'm not sure who should be
> required to do it, if the payer or the recipient.
The payer is already cryptographically bound to the transaction by his
promise. The commit is the recipient's way of being bound.
We also don't want to allow the payer to issue a rollback
unilaterally, since he would be motivated to do so after issuing a
commit and taking delivery of the goods.
>
> Ok, having rollback has advantages. But in this case, if the work of a
> "mini-block" can be used to calculate the total work for a block, the
> the one that spends more CPU in the transaction wins. It doesn't
> matter what message was sent first.
> An attacker with enough CPU power, could start transactions commit
> them and then rollback them with highly difficult proof. Than would
> lock the credit of the intermediaries too.
Yes, this is exactly the weakness of the block chain, being able to go
back and rewrite history if you have enough CPU power. But the
existence of an explicit rollback message doesn't really change this.
Since only recipients can create commits and rollbacks, the real
attack is that a recipient signals a rollback, either by an explicit
rollback message, or by failing to issue a commit, and then later gets
a commit inserted into the chain once the payer is unable or unlikely
to claim any goods from the recipient. Examples are a face-to-face
street transaction where the payer does not know the recipient, or a
store where the payer is unlikely to return after she leaves. These
types of transactions obviously need a real-time commit decision
either way, and aren't suitable for the block chain in the first
place.
Transactions suitable for using the block chain are ones where the
payer knows the recipient well enough to be able to claim her value if
a payment is committed late, or is willing to wait with the recipient
until a commit decision is sufficiently cemented in the block chain.
So here's why an explicit rollback message is useful:
1. If both a rollback and commit are issued, the payer knows the
recipient is attempting to cheat. Therefore, if the recipient wanted
to cheat, and cares if the payer finds out, he would not issue a
rollback. Much better to just not issue any decision, and then issue
a late commit and try to get it included retroactively, and claim that
it didn't get included early because of communication issues somewhere
in the network. Tough to see where this would be a great attack
though.
2. Once a rollback is issued, that decision starts getting cemented
in the block chain immediately, meaning certainty is reached sooner
than if the payer has to wait for the promises to expire with no
commit in the block chain before the rollback decision can even begin
to be cemented in the block chain. This is the main advantage of the
rollback.
Notice that the difficulty in reversing a decision is the same
regardless of whether there's an explicit rollback or not: it is
proportional to the length of the chain after the decision is set.
The rollback just allows that decision to be set earlier.
Ryan
Jorge Timón
proposal of adding the work of the orphan blocks and mini-blocks is
not viable if colliding transactions can be received, because if they
are sent during the formation of the same block, the one with more
work will win (instead of the one that was sent first). We can reduce
the time between blocks to make this possibility less likely, but the
more we reduce the time between blocks, the more forks of the chain
will appear.
Another thing, the reason we give for discarding the merges was that
it allows timestamping to be cheated. Could that be avoided by
requiring the branches certain minimum work proof (length of chain) to
be merged? The rollback would be imposible in this case.
2011/4/21, Ryan Fugger <a...@ryanfugger.com>:
Ryan Fugger
> Yes, the the difficulty in reversing a decision is the same, but my
> proposal of adding the work of the orphan blocks and mini-blocks is
> not viable if colliding transactions can be received, because if they
> are sent during the formation of the same block, the one with more
> work will win (instead of the one that was sent first). We can reduce
> the time between blocks to make this possibility less likely, but the
> more we reduce the time between blocks, the more forks of the chain
> will appear.
>
I don't see the harm if two contradictory orders are issued for
inclusion in the same block -- only one will be chosen, and you need
to wait for this block regardless before you decide whether to redeem
or release your promises. The fact that the recipient can choose
whether commit or rollback is included is already true.
It also reflects very badly on the recipient, which may or may not
make a difference to anything.
> Another thing, the reason we give for discarding the merges was that
> it allows timestamping to be cheated. Could that be avoided by
> requiring the branches certain minimum work proof (length of chain) to
> be merged? The rollback would be imposible in this case.
>
No, because then it would just take longer to cheat.
Ryan
Jorge Timón
> inclusion in the same block -- only one will be chosen, and you need
> to wait for this block regardless before you decide whether to redeem
> or release your promises. The fact that the recipient can choose
> whether commit or rollback is included is already true.
>
> It also reflects very badly on the recipient, which may or may not
> make a difference to anything.
You're right. The recipient of the message can do whatever he wants
even if he hasn't any incentive to make a choice.
The protocol can define whoever (the payer or the seller) to be the
last to sign the transaction before sending it to the chain. We should
chose the less likely to cheat the block chain.
Is it the seller?
How can the payer and the seller try to cheat the block chain?
After signing, comes the proof of work which can be made for any of
the two (or both to increase the chances of being included fast).
I guess both have an incentive in this case.
>> Another thing, the reason we give for discarding the merges was that
>> it allows timestamping to be cheated. Could that be avoided by
>> requiring the branches certain minimum work proof (length of chain) to
>> be merged? The rollback would be imposible in this case.
>>
>
> No, because then it would just take longer to cheat.
Mmhmm. What if (apart from requiring a minimum work) a maximum
distance (in proof of work) to the main chain is set to be a mergeable
branch.
Or this limits could be function of one another. The more the
difference in length (in work) between the two branches, the higher
the minimum size for the smaller one to be merged.
Ryan Fugger
> The protocol can define whoever (the payer or the seller) to be the
> last to sign the transaction before sending it to the chain. We should
> chose the less likely to cheat the block chain.
> Is it the seller?
The recipient (seller) *must* sign, the payer need not, because he has already
issued a promise that binds him to the transaction.
> How can the payer and the seller try to cheat the block chain?
>
The attack for a payer and recipient in league would be to get IOUs
passed to the recipient without having the payer pass any IOUs
forward. So the recipient would issue a commit, get it sufficiently
cemented in the block chain so that the recipient could claim his IOU
from the last intermediary, but then create a more difficult chain
either including a rollback, or excluding the commit until the payer's
promise expired. (The last intermediary does not necessarily know
that his neighbour is the recipient, and so cannot necessarily blame
him for a conflicting commit/rollback.)
One way to do this might be for a node to pre-calculate a very
difficult proof of work for the rollback, and use it to fork the chain
prior to the commit, and overwhelm the commit branch. This
precalculation attack would be mitigated if every intermediary could
add a nonce to their promise that had to be included in any
commit/rollback for it to be valid.
>
> Mmhmm. What if (apart from requiring a minimum work) a maximum
> distance (in proof of work) to the main chain is set to be a mergeable
> branch.
> Or this limits could be function of one another. The more the
> difference in length (in work) between the two branches, the higher
> the minimum size for the smaller one to be merged.
>
That could probably work, but what's the need if we can already pick
up individual commits and rollbacks from orphan branches and included
them in the main branch, albeit at a later time?
Ryan
Jorge Timón
> 2011/4/22 Jorge Timón <timon....@gmail.com>:
>> The protocol can define whoever (the payer or the seller) to be the
>> last to sign the transaction before sending it to the chain. We should
>> chose the less likely to cheat the block chain.
>> Is it the seller?
>
> The recipient (seller) *must* sign, the payer need not, because he has
> already
> issued a promise that binds him to the transaction.
What I mean is that if the protocol says the payer must sign the
transaction again before commit to the block chain then the payer must
sign the last. So we can chose the last participant to sign depending
on how hard is for him to cheat.
>> How can the payer and the seller try to cheat the block chain?
>>
>
> The attack for a payer and recipient in league would be to get IOUs
> passed to the recipient without having the payer pass any IOUs
> forward. So the recipient would issue a commit, get it sufficiently
> cemented in the block chain so that the recipient could claim his IOU
> from the last intermediary, but then create a more difficult chain
> either including a rollback, or excluding the commit until the payer's
> promise expired. (The last intermediary does not necessarily know
> that his neighbour is the recipient, and so cannot necessarily blame
> him for a conflicting commit/rollback.)
Does the recipient need the payer for this?
> One way to do this might be for a node to pre-calculate a very
> difficult proof of work for the rollback, and use it to fork the chain
> prior to the commit, and overwhelm the commit branch. This
> precalculation attack would be mitigated if every intermediary could
> add a nonce to their promise that had to be included in any
> commit/rollback for it to be valid.
Does the recipient starts the pre-calculation when he receives the
transaction (and before sending the commit) or when the payer (his
pal) sends him the transaction ID ?
>>
>> Mmhmm. What if (apart from requiring a minimum work) a maximum
>> distance (in proof of work) to the main chain is set to be a mergeable
>> branch.
>> Or this limits could be function of one another. The more the
>> difference in length (in work) between the two branches, the higher
>> the minimum size for the smaller one to be merged.
>>
>
> That could probably work, but what's the need if we can already pick
> up individual commits and rollbacks from orphan branches and included
> them in the main branch, albeit at a later time?
If branches can be merged, forks are not a problem (or are a smaller problem).
If forks are not a problem, we don't need a target block generation
rate nor a target difficulty. We could just set a minimum difficulty.
This would reduce the waiting for confirmation.
Ryan Fugger
> 2011/4/22, Ryan Fugger <a...@ryanfugger.com>:
>> The recipient (seller) *must* sign, the payer need not, because he has
>> already
>> issued a promise that binds him to the transaction.
>
> What I mean is that if the protocol says the payer must sign the
> transaction again before commit to the block chain then the payer must
> sign the last. So we can chose the last participant to sign depending
> on how hard is for him to cheat.
>
There's no need for the protocol to say the payer must sign the
commit. If it did (as the current draft does), he would sign *before*
the recipient did, since the commit is used as part of the payer's
proof of payment, and he must not get it before the payment is
actually committed.
>> The attack for a payer and recipient in league would be to get IOUs
>> passed to the recipient without having the payer pass any IOUs
>> forward. So the recipient would issue a commit, get it sufficiently
>> cemented in the block chain so that the recipient could claim his IOU
>> from the last intermediary, but then create a more difficult chain
>> either including a rollback, or excluding the commit until the payer's
>> promise expired. (The last intermediary does not necessarily know
>> that his neighbour is the recipient, and so cannot necessarily blame
>> him for a conflicting commit/rollback.)
>
> Does the recipient need the payer for this?
>
Only to profit.
>> One way to do this might be for a node to pre-calculate a very
>> difficult proof of work for the rollback, and use it to fork the chain
>> prior to the commit, and overwhelm the commit branch. This
>> precalculation attack would be mitigated if every intermediary could
>> add a nonce to their promise that had to be included in any
>> commit/rollback for it to be valid.
>
> Does the recipient starts the pre-calculation when he receives the
> transaction (and before sending the commit) or when the payer (his
> pal) sends him the transaction ID ?
>
It would make the most sense to have everything precalculated before
the promises are made.
>> That could probably work, but what's the need if we can already pick
>> up individual commits and rollbacks from orphan branches and included
>> them in the main branch, albeit at a later time?
>
> If branches can be merged, forks are not a problem (or are a smaller problem).
> If forks are not a problem, we don't need a target block generation
> rate nor a target difficulty. We could just set a minimum difficulty.
> This would reduce the waiting for confirmation.
>
We don't need target difficulty either way, do we?
Ryan
Ryan Fugger
(including a block chain for commits) to handle rollbacks. Here's how
a promise issuing node would decide whether it must fulfill the
promise. Lower statements in the list only apply if higher statements
have not resolved the issue yet.
1. If the promise holder has issued a promise release, and an IOU has
not yet been issued, then the promise is released.
2. If the promise does not require registries to validate a commit,
and the promise holder presents a valid commit before the promise
expiry, then the promise must be fulfilled. (Although the promisor
might pretend not to receive the commit in time.)
3. If the registries specified on the promise have validated a commit
with a timestamp earlier than the promise expiry, then the promise
must be fulfilled.
4. If the registries specified on the promise state that they have
not received a commit by promise expiry, then the promise is released.
5. If the promise expiry time has passed, the promise is released.
My problem before was if the recipient issued a promise release, but
then submitted a commit to the registries. I had thought that the
registries' commit should supersede the promise release, making the
unilateral promise release meaningless. But there's no need to make
the registries' commit trump the recipient's promise release. It
works better the other way around, and makes the system less dependent
on registries, which is a good thing.
Since the recipient (or any promise holder) can only issue a promise
release for the specific promise they hold, there is no risk in
conflicting messages being used to screw things up further up the
chain.
Ryan
Jorge Timón
> 2011/4/22 Jorge Timón <timon....@gmail.com>:
>> 2011/4/22, Ryan Fugger <a...@ryanfugger.com>:
>>> The recipient (seller) *must* sign, the payer need not, because he has
>>> already
>>> issued a promise that binds him to the transaction.
>>
>> What I mean is that if the protocol says the payer must sign the
>> transaction again before commit to the block chain then the payer must
>> sign the last. So we can chose the last participant to sign depending
>> on how hard is for him to cheat.
>>
>
> There's no need for the protocol to say the payer must sign the
> commit. If it did (as the current draft does), he would sign *before*
> the recipient did, since the commit is used as part of the payer's
> proof of payment, and he must not get it before the payment is
> actually committed.
>
>>> The attack for a payer and recipient in league would be to get IOUs
>>> passed to the recipient without having the payer pass any IOUs
>>> forward. So the recipient would issue a commit, get it sufficiently
>>> cemented in the block chain so that the recipient could claim his IOU
>>> from the last intermediary, but then create a more difficult chain
>>> either including a rollback, or excluding the commit until the payer's
>>> promise expired. (The last intermediary does not necessarily know
>>> that his neighbour is the recipient, and so cannot necessarily blame
>>> him for a conflicting commit/rollback.)
>
>>> difficult proof of work for the rollback, and use it to fork the chain
>>> prior to the commit, and overwhelm the commit branch. This
>>> precalculation attack would be mitigated if every intermediary could
>>> add a nonce to their promise that had to be included in any
>>> commit/rollback for it to be valid.
>>
>> Does the recipient starts the pre-calculation when he receives the
>> transaction (and before sending the commit) or when the payer (his
>> pal) sends him the transaction ID ?
>>
>
> It would make the most sense to have everything precalculated before
> the promises are made.
Instead (or plus) of a nonce, intermediaries could just add the hash
of the top block (of the chain they know).
>
>>> That could probably work, but what's the need if we can already pick
>>> up individual commits and rollbacks from orphan branches and included
>>> them in the main branch, albeit at a later time?
>>
>> If branches can be merged, forks are not a problem (or are a smaller
>> problem).
>> If forks are not a problem, we don't need a target block generation
>> rate nor a target difficulty. We could just set a minimum difficulty.
>> This would reduce the waiting for confirmation.
>>
>
> We don't need target difficulty either way, do we?
>
If we want to prevent forks (and if they can cancel transactions that
were valid, we want to prevent them), we need a target block
generation rate, so the top block is know by the whole network before
the next block is created.
Jorge Timón
> (including a block chain for commits) to handle rollbacks. Here's how
> a promise issuing node would decide whether it must fulfill the
> promise. Lower statements in the list only apply if higher statements
> have not resolved the issue yet.
>
> 1. If the promise holder has issued a promise release, and an IOU has
> not yet been issued, then the promise is released.
>
> 2. If the promise does not require registries to validate a commit,
> and the promise holder presents a valid commit before the promise
> expiry, then the promise must be fulfilled. (Although the promisor
> might pretend not to receive the commit in time.)
And the payer might pretend not to receive the promise release in 1.
It's no possible to know what happened before without registries, is it?
> 3. If the registries specified on the promise have validated a commit
> with a timestamp earlier than the promise expiry, then the promise
> must be fulfilled.
>
> 4. If the registries specified on the promise state that they have
> not received a commit by promise expiry, then the promise is released.
>
> 5. If the promise expiry time has passed, the promise is released.
It's no possible to know if a promise has expired without registries, is it?
> My problem before was if the recipient issued a promise release, but
> then submitted a commit to the registries. I had thought that the
> registries' commit should supersede the promise release, making the
> unilateral promise release meaningless. But there's no need to make
> the registries' commit trump the recipient's promise release. It
> works better the other way around, and makes the system less dependent
> on registries, which is a good thing.
>
> Since the recipient (or any promise holder) can only issue a promise
> release for the specific promise they hold, there is no risk in
> conflicting messages being used to screw things up further up the
> chain.
But then they can issue the promise release after some of the
participants have spend the credit they gained with the commit.
That would make the commits reversible.
Ryan Fugger
>
> If we want to prevent forks (and if they can cancel transactions that
> were valid, we want to prevent them), we need a target block
> generation rate, so the top block is know by the whole network before
> the next block is created.
>
We can't prevent forks. Anyone can always fork, and, if they have
enough CPU power, eventually create the longest chain, excluding any
commits they didn't like. This is in the very nature of the block
chain.
The only real reason I can see for requiring a target difficulty is to
minimize network traffic. Without a target difficulty, servers would
want pile little bits of work on top of their commits continuously,
rather than spend hours or days accomplishing a really significant
proof. Unfortunately, the goal of minimizing traffic is at odds with
the goal of wanting a fluid block chain where one's commits are
included quickly.
Ryan
Ryan Fugger
>> 1. If the promise holder has issued a promise release, and an IOU has
>> not yet been issued, then the promise is released.
>>
>> 2. If the promise does not require registries to validate a commit,
>> and the promise holder presents a valid commit before the promise
>> expiry, then the promise must be fulfilled. (Although the promisor
>> might pretend not to receive the commit in time.)
>
> And the payer might pretend not to receive the promise release in 1.
> It's no possible to know what happened before without registries, is it?
>
There's no incentive for a promisor to pretend to not receive a
promise release, so we don't need to worry about that I don't think.
>> 3. If the registries specified on the promise have validated a commit
>> with a timestamp earlier than the promise expiry, then the promise
>> must be fulfilled.
>>
>> 4. If the registries specified on the promise state that they have
>> not received a commit by promise expiry, then the promise is released.
>>
>> 5. If the promise expiry time has passed, the promise is released.
>
> It's no possible to know if a promise has expired without registries, is it?
>
Sure it is. If the promise does not specify any registries, and it
says it expires at midnight, and it is past midnight, then the promise
has expired. End of story. The promisor can decide this
unilaterally, since it did not specify any registries.
The protocol will specify that the promise holder should issue a
promise release when the promise expires, but that may not be possible
if, for example, the promise holder is offline.
>> My problem before was if the recipient issued a promise release, but
>> then submitted a commit to the registries. I had thought that the
>> registries' commit should supersede the promise release, making the
>> unilateral promise release meaningless. But there's no need to make
>> the registries' commit trump the recipient's promise release. It
>> works better the other way around, and makes the system less dependent
>> on registries, which is a good thing.
>>
>> Since the recipient (or any promise holder) can only issue a promise
>> release for the specific promise they hold, there is no risk in
>> conflicting messages being used to screw things up further up the
>> chain.
>
> But then they can issue the promise release after some of the
> participants have spend the credit they gained with the commit.
> That would make the commits reversible.
>
No, a promise release can only undo a commit if an IOU has not yet
been issued. Once the IOU is issued, it is final. And you cannot
spend credit until the IOU comes.
It is theoretically possible for the recipient or an intermediary to
pass a commit to their promisor, and then quickly issue a promise
release before receiving an IOU. That action can only lose them the
value of the payment though, since if an intermediary does it, they
must still pay an IOU forward, and if the recipient does it, they must
still deliver goods to the payer, since she will have a proof of
payment (payment-accept + commit). So there is nothing to gain by
doing this, and it doesn't otherwise disrupt the transaction if it is
done accidentally.
Ryan
Jorge Timón
> enough CPU power, eventually create the longest chain, excluding any
> commits they didn't like. This is in the very nature of the block
> chain.
Well, not anyone. You need CPU power and luck. The smaller the target
difficulty, the less you need to create a block.
> The only real reason I can see for requiring a target difficulty is to
> minimize network traffic. Without a target difficulty, servers would
> want pile little bits of work on top of their commits continuously,
> rather than spend hours or days accomplishing a really significant
> proof. Unfortunately, the goal of minimizing traffic is at odds with
> the goal of wanting a fluid block chain where one's commits are
> included quickly.
I think 10 minutes is the estimated time for a new block to be
received by the whole network without another block being created.
I'll ask it in the bitcoin forum because I can't find it in the wiki.
Jorge Timón
Jorge Timón
http://www.bitcoin.org/smf/index.php?topic=6373.0
2011/4/23, Jorge Timón <timon....@gmail.com>:
Jorge Timón
> 2011/4/22 Jorge Timón <timon....@gmail.com>:
>>> 1. If the promise holder has issued a promise release, and an IOU has
>>> not yet been issued, then the promise is released.
>>>
>>> 2. If the promise does not require registries to validate a commit,
>>> and the promise holder presents a valid commit before the promise
>>> expiry, then the promise must be fulfilled. (Although the promisor
>>> might pretend not to receive the commit in time.)
>>
>> And the payer might pretend not to receive the promise release in 1.
>> It's no possible to know what happened before without registries, is it?
>>
>
> There's no incentive for a promisor to pretend to not receive a
> promise release, so we don't need to worry about that I don't think.
But there's an incentive for the payer to pretend to not receive it in
time. Without commit arbiters/registries there's no way to know what
happen first.
The payer will say that the commit happened first and the transaction
is valid even if a promise release was issued first.
The recipient could use a pal intermediary to issue a commit release
after the commit is made. What happened first?
>>> 3. If the registries specified on the promise have validated a commit
>>> with a timestamp earlier than the promise expiry, then the promise
>>> must be fulfilled.
>>>
>>> 4. If the registries specified on the promise state that they have
>>> not received a commit by promise expiry, then the promise is released.
>>>
>>> 5. If the promise expiry time has passed, the promise is released.
>> It's no possible to know if a promise has expired without registries, is
>> it?
>>
>
> Sure it is. If the promise does not specify any registries, and it
> says it expires at midnight, and it is past midnight, then the promise
> has expired. End of story. The promisor can decide this
> unilaterally, since it did not specify any registries.
Ok, let's say the expiration says "26/04/2011 00:00:00". What clock
are we watching?
The promise release doesn't have time field and the time field in the
commit token can be cheated.
How do we know what happened first in case of conflict?
Ryan Fugger
> 2011/4/23, Ryan Fugger <a...@ryanfugger.com>:
>> There's no incentive for a promisor to pretend to not receive a
>> promise release, so we don't need to worry about that I don't think.
>
> But there's an incentive for the payer to pretend to not receive it in
> time.
What's the incentive?
> Without commit arbiters/registries there's no way to know what
> happen first.
> The payer will say that the commit happened first and the transaction
> is valid even if a promise release was issued first.
> The recipient could use a pal intermediary to issue a commit release
> after the commit is made. What happened first?
>
I don't see how anyone can benefit from this, or anyone lose value
without explicitly giving it away, so it seems fine to me.
>> Sure it is. If the promise does not specify any registries, and it
>> says it expires at midnight, and it is past midnight, then the promise
>> has expired. End of story. The promisor can decide this
>> unilaterally, since it did not specify any registries.
>
> Ok, let's say the expiration says "26/04/2011 00:00:00". What clock
> are we watching?
If there are no registries, the promisor's own clock is authoritative.
> The promise release doesn't have time field and the time field in the
> commit token can be cheated.
> How do we know what happened first in case of conflict?
>
The promisor decides unilaterally.
Ryan
Jorge Timón
> 2011/4/25 Jorge Timón <timon....@gmail.com>:
>> 2011/4/23, Ryan Fugger <a...@ryanfugger.com>:
>>> There's no incentive for a promisor to pretend to not receive a
>>> promise release, so we don't need to worry about that I don't think.
>>
>> But there's an incentive for the payer to pretend to not receive it in
>> time.
>
> What's the incentive?
To make the transaction.
>
>> Without commit arbiters/registries there's no way to know what
>> happen first.
>> The payer will say that the commit happened first and the transaction
>> is valid even if a promise release was issued first.
>> The recipient could use a pal intermediary to issue a commit release
>> after the commit is made. What happened first?
>>
>
> I don't see how anyone can benefit from this, or anyone lose value
> without explicitly giving it away, so it seems fine to me.
If there's a commit an a promise release, some of the promisors will
issue their IOUs while others (the one that has issued the promise
release, for example) that won't.
>>> Sure it is. If the promise does not specify any registries, and it
>>> says it expires at midnight, and it is past midnight, then the promise
>>> has expired. End of story. The promisor can decide this
>>> unilaterally, since it did not specify any registries.
>>
>> Ok, let's say the expiration says "26/04/2011 00:00:00". What clock
>> are we watching?
>
> If there are no registries, the promisor's own clock is authoritative.
>
>> The promise release doesn't have time field and the time field in the
>> commit token can be cheated.
>> How do we know what happened first in case of conflict?
>>
>
> The promisor decides unilaterally.
Then what prevents him from issuing a promise release after he has
received the commit?
Ryan Fugger
> 2011/4/26, Ryan Fugger <a...@ryanfugger.com>:
>> 2011/4/25 Jorge Timón <timon....@gmail.com>:
>>> 2011/4/23, Ryan Fugger <a...@ryanfugger.com>:
>>>> There's no incentive for a promisor to pretend to not receive a
>>>> promise release, so we don't need to worry about that I don't think.
>>>
>>> But there's an incentive for the payer to pretend to not receive it in
>>> time.
>>
>> What's the incentive?
>
> To make the transaction.
>
You're going to have to spell out the problem for me here, because I
don't see what you're getting at.
>>
>>> Without commit arbiters/registries there's no way to know what
>>> happen first.
>>> The payer will say that the commit happened first and the transaction
>>> is valid even if a promise release was issued first.
>>> The recipient could use a pal intermediary to issue a commit release
>>> after the commit is made. What happened first?
>>>
>>
>> I don't see how anyone can benefit from this, or anyone lose value
>> without explicitly giving it away, so it seems fine to me.
>
> If there's a commit an a promise release, some of the promisors will
> issue their IOUs while others (the one that has issued the promise
> release, for example) that won't.
>
So what?
>>> The promise release doesn't have time field and the time field in the
>>> commit token can be cheated.
>>> How do we know what happened first in case of conflict?
>>>
>>
>> The promisor decides unilaterally.
>
> Then what prevents him from issuing a promise release after he has
> received the commit?
>
Nothing. But he wouldn't want to and it wouldn't hurt anything if he
did. So it doesn't matter.
Ryan
Jorge Timón
The transaction would be like this:
A -> B -> C -> D
Everyone signs the promise.
1) D issues the commit.
2) A and B issue their IOU.
3) C issues a commit release.
C claims that he has issued the commit release before receiving the
commit and the IOU.
Ryan Fugger
> Maybe I can explain myself better with an example.
> The transaction would be like this:
>
> A -> B -> C -> D
>
> Everyone signs the promise.
> 1) D issues the commit.
> 2) A and B issue their IOU.
> 3) C issues a commit release.
>
> C claims that he has issued the commit release before receiving the
> commit and the IOU.
>
So you're saying C is refusing to issue an IOU? That has nothing to
do with whether he issued a promise release to B. D never released
C's promise, so C must honour it if he received a commit from D before
the promise expired. To pretend he does not need to issue an IOU, C
would have to pretend he never received such a commit, which is the
exact problem registries solve. If D accepted C's promise without
registries, then she trusted C to not behave like this. If D was late
with the commit, then she should have issued a promise release
instead.
In other words, this is all fine.
Ryan
Jorge Timón
> 2011/4/26 Jorge Timón <timon....@gmail.com>:
>> Maybe I can explain myself better with an example.
>> The transaction would be like this:
>>
>> A -> B -> C -> D
>>
>> Everyone signs the promise.
>> 1) D issues the commit.
>> 2) A and B issue their IOU.
>> 3) C issues a commit release.
>>
>> C claims that he has issued the commit release before receiving the
>> commit and the IOU.
>>
>
> So you're saying C is refusing to issue an IOU? That has nothing to
> do with whether he issued a promise release to B. D never released
> C's promise, so C must honour it if he received a commit from D before
> the promise expired.
Is D who has to release C's promise? What would he do that?
In this case, C and D have a trust relationship, but what if were B
who issued the promise release?
> To pretend he does not need to issue an IOU, C
> would have to pretend he never received such a commit, which is the
> exact problem registries solve. If D accepted C's promise without
> registries, then she trusted C to not behave like this. If D was late
> with the commit, then she should have issued a promise release
> instead.
>
> In other words, this is all fine.
If I got it right, it's all fine only if there's registries involved.
Jorge Timón
2011/4/26, Jorge Timón <timon....@gmail.com>:
Ryan Fugger
> 2011/4/26, Ryan Fugger <a...@ryanfugger.com>:
>>
>> So you're saying C is refusing to issue an IOU? That has nothing to
>> do with whether he issued a promise release to B. D never released
>> C's promise, so C must honour it if he received a commit from D before
>> the promise expired.
>
I don't know.
> In this case, C and D have a trust relationship, but what if were B
> who issued the promise release?
>
B can only release A's promise.
>> To pretend he does not need to issue an IOU, C
>> would have to pretend he never received such a commit, which is the
>> exact problem registries solve. If D accepted C's promise without
>> registries, then she trusted C to not behave like this. If D was late
>> with the commit, then she should have issued a promise release
>> instead.
>>
>> In other words, this is all fine.
>
> If I got it right, it's all fine only if there's registries involved.
>
No, it's fine if everyone stays online and honours their promises.
Ryan
Jorge Timón
PromiseRelease. "
I missed that, sorry.
So B can release A's promise, C can release B's promise and D can
release C's promise.
I thought the last signer (D) was the one who release all the
promises, because he's the one who can issue the commit.
B can't release his own promise. If he wants to, he ask C for the
release who will ask D to release his own. If during that time D
issues the commit the transaction is valid. If he receives the
"release petition" before he signs the commit, he shouldn't sign it.
He could sign it anyway, but C knows that he has sent the release
before receiving the commit and he has a trust relationship with D.
Is that right?
There's no "release petition" message in the draft. Isn't it necessary?
2011/4/26, Ryan Fugger <a...@ryanfugger.com>:
Ryan Fugger
> B can't release his own promise. If he wants to, he ask C for the
> release who will ask D to release his own. If during that time D
> issues the commit the transaction is valid. If he receives the
> "release petition" before he signs the commit, he shouldn't sign it.
> He could sign it anyway, but C knows that he has sent the release
> before receiving the commit and he has a trust relationship with D.
>
> Is that right?
> There's no "release petition" message in the draft. Isn't it necessary?
>
I'm not sure it's really necessary. When would a node change its mind
about a promise? I would imagine that usually the commit or release
will come only a few seconds after the promise anyways. If a node
doesn't want to perform a transaction, it shouldn't accept or make a
promise that it will perform the transaction (and shouldn't advertise
the available credit either).
I'm happy to leave it out for now and add it in later if it proves
necessary for some reason.
Ryan
Jorge Timón
As there's no expiry time (if so, who has the "authority clock"?) for
promises without registries, the node could change his mind about a
promise if the transaction takes too long to commit. That's what the
promise release are for, right?
Ryan Fugger
>> I'm not sure it's really necessary. When would a node change its mind
>> about a promise? I would imagine that usually the commit or release
>> will come only a few seconds after the promise anyways. If a node
>> doesn't want to perform a transaction, it shouldn't accept or make a
>> promise that it will perform the transaction (and shouldn't advertise
>> the available credit either).
>
> As there's no expiry time (if so, who has the "authority clock"?) for
> promises without registries, the node could change his mind about a
> promise if the transaction takes too long to commit. That's what the
> promise release are for, right?
>
There is most definitely an expiry for promises without registries.
The promisor has the "authority clock".
Ryan
Jorge Timón
B "feels" (with his clock) that his promise has expired.
C releases B's promise and "at the same time", D commits.
How can be known what happened first?
Is that transaction valid or invalid?
2011/4/27, Ryan Fugger <a...@ryanfugger.com>:
Ryan Fugger
> I the previous example.
> B "feels" (with his clock) that his promise has expired.
> C releases B's promise and "at the same time", D commits.
> How can be known what happened first?
> Is that transaction valid or invalid?
>
C gives its promise to D an earlier expiry than the promise it holds
from B to prevent this from happening. But if it did happen for some
reason, and C's promise was still valid, it would bear the full cost
of the transaction. There is no such thing as a "valid" or "invalid"
transaction, only which IOUs get passed. In this case, only C's would
get passed. It should be noted that if C and D did not otherwise
publish the commit token, then the payer (A) would not have it, and so
would not be able to prove payment was made.
Ryan
Jorge Timón
It seems to me that registries are pretty necessary then.
For me that's not a problem, because a block chain registry would be
possible (although probably less efficient), removing the necessity of
third parties for atomicity.
The most simple registry would just answer with the state of a certain
requested transaction with 3 possible answers:
-Completed (and proof).
-Expired (or canceled if the registry allows promise releases)
-In progress
The hypothetical mergeable chain (maybe not, but I think it would be
feasible) won't allow promise releases, just expiry times for the
promises. Would it be compatible with the protocol (as registry) ?
2011/4/28, Ryan Fugger <a...@ryanfugger.com>: