Recent Changes - Search:
Main /

CommitScripts

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

  1. Both parties generates a new key and some random data (the secret).
  2. Party B sends a hash of his secret to A along with his public key.
  3. Party A generates Tx1 (the payment) containing an output with the chain-trade script in it. See below for this script and a discussion of it. It allows coin release either by signing with the two keys (key A and key B) or with (secret A, secret B, key B). This transaction is not broadcast. The chain release script contains hashes, not the actual secrets themselves.
  4. Party A generates Tx2 (the contract) which spends Tx1 and has an output going back to key A. It has a lock time of some point in the future and the input has a sequence number of zero, so it can be replaced. A signs Tx2 and sends it to B, who also signs it and sends it back. Alternatively they can simply agree on what form the contract takes, eg by using the same software, and then A can simply send B the hash of Tx1 and receive back a signature.
  5. A broadcasts Tx1 and Tx2. Party B can now see the coins but cannot spend them because it does not have an output going to him, and the tx is not finalized anyway.
  6. B performs a ripple transaction that requires secret A and secret B. Both sides of the trade are now pending but incomplete.
  7. A sends his secret (random data) to B, who then uses it to re-issue the now finalized contract using (secret A, secret B, key B) and an output of his choice. B now owns the coins but in the process of claiming them, revealed his secret, allowing A to claim the other side of the trade (allowing A to finalize the ripple commit).

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.