BareCommitMethod
Ripple Protocol Commit Method: Bare
See Commit Methods.
In this commit method, the recipient generates a secret commit token, and then passes it back through the chain of intermediaries to the payer. This method is *not* atomic, however, since it is possible for participants to cheat and not get caught.
The bare commit method is a special case of the registry commit method, and takes that as a starting point. The difference is that the participants do not indicate ahead of time that they trust the registry used. The recipient can choose whatever registry it wants, including acting as the registry itself, or, if it is lazy, specifying the null registry:
urn:ripple:registry:null
Commit Method Name
This commit method is called bare.
Network & Routing
The trusted registry list from the registry commit method is ignored, except for the max deadline length.
Cheating & Stalled Commits
The fact of the registry not being known or trusted, or even existing necessarily, leaves this commit method vulnerable to communication outages and cheating. If there is an issue passing the commit message back along the intermediaries, during which time the still-outstanding Promises expire, the transaction may be left half-committed without a trusted authority to remedy the situation.
An unscrupulous hub could, among other things, pretend not to receive the commit message when it arrives in order to profit, either by passing it further down, or by being the payer and recipient in a circular payment. It could then blame the other hub's server for the communication outage, and claim it cannot accept a late commit because of other hubs further down the chain (whether or not they even exist).
The bare commit method requires voluntary cooperation from all hubs in order to work reliably:
- A hub that receives a commit, either from a neighbour or from the untrusted registry, must pass IOUs forward to redeem all promises it has issued for that transaction that have not expired or been released.
- A hub that has received all its IOUs for a transaction must redeem all unreleased promises it has issued, even if they have expired.
- A hub should attempt to redeem any unreleased expired promises it holds by passing the commit message to the promise issuer(s), even when it causes a line of credit balance to surpass its credit limit. It may, however, decide not to do this if the amount over limit would be unacceptable.
- Payers must honour unreleased expired promises, even if the commit message is late.