This proposal is intended to replace the registries proposal. it is inspired in bitcoin scripts The idea would be to substitute the commit_key field for a commit_script field. For a signed promise to be valid, all conditions appearing in the promise commit script must also appear in the transaction. Let's see how this would work with examples.
1. Regular behaviour.
Without registries, only requiring the recipient signature:
The PaymentAccept message contains OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
To obtain true for this script you need: scriptSig: <sig> <pubKey>
2. Registry behaviour.
For transactions with registries:
Let's say we have the following transaction A -> B -> C -> D and there are two registries r1 and r2
B includes in his promise script: OP_DUP OP_HASH160 <r1pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
C includes in his promise script OP_DUP OP_HASH160 <r2pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
The PaymentAccept message contains
OP_DUP OP_HASH160 <r1pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG OP_DUP OP_HASH160 <r2pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
That is, it contains both registries. Maybe it also contains:
OP_DUP OP_HASH160 <DpubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
To obtain true with this script you need: scriptSig: <r2sig> <r2pubKey> <r1sig> <r1pubKey>
If the recipient had also added his signature to the script, the validation would need:
scriptSig: <Dsig> <DpubKey> <r2sig> <r2pubKey> <r1sig> <r1pubKey>
The registries can be combined in any way using OP_BOOLAND and OP_BOOLOR. For example, B could have asked for r1 AND r3 or C could have asked for r2 OR r4 Two from a list of 4 or whatever the intermediary needs for the transaction to be secure to him.
These scripts not only allow registries to participate in the ripple transactions, they allow other interesting things. Probably people will came up with new applications. Once the protocol allows scripts, it doesn't need to be changed to allow new commit conditions and the protocol can be extended easily. Some applications for scripts:
3. Trust-less atomic exchange between ripple credits and bitcoins
Using a set up similar to the one needed for trust-less exchange between different block chain currencies (say a decentralized btc/nmc exchange), one can trade directly a block chain currency in exchange of ripple credits. Let's say party A pays bitcoins and B pays ripple credits
4. Buy smart property for ripple credits.
With a similar setup to the previous one, but Party A transfer the smart property instead of regular bitcoins.
5. Acting as intermediary while being offline without giving other ripple server temporal control over your keys.
If promises were trades (between two ripple currencies/IOUs), an intermediary could sign them in advance (binding advertisements) and broadcast them, allowing him to participate as intermediary being offline. He should set a registry in the script that would control the credit limit (prevent "double-spending").
Probably more applications will appear just as more applications are appearing for bitcoin scripts. The proposal removes the necessity for implementing registries directly, allows more possibilities for ripple and improves ripple interoperability with block chain currencies and services.