To prepare the lock of tokens, the seller creates a modifiable and expandable blank transaction, spending the output directed to the script locked destination, and requests the oracle to sign this transaction.
Because the oracle will only sign one single transaction from the
script locked destination, the seller requests the oracle to sign a
blank transaction spending the output with the signature hash flags
"NONE|ANYONECANPAY"
. This transaction then serves as wild card, and
due to the flags it becomes possible to add additional inputs or
outputs. This way the seller can create an arbitrary number of
transactions spending this one locked output, but the seller can't
create any other transaction spending from the locked destination.
This use-case describes the process of preparing a blank wild card transaction, which is signed by the oracle.
- Swap client
- User-goal
- Seller
- Oracle
- The seller configured the system's settings to connect to a running Bitcoin or Omni Core RPC server
- The seller configured the system's settings to connect to a running oracle server
- The seller generated a script locked destination (UC-Client-1)
- The seller prepared a funding transaction (UC-Client-2)
- The seller requests to create a signed transaction stub
- The seller provides the hash of the signed funding transaction, the index of the funding output to the script lock destination, the corresponding scriptPubKey, the redeemScript for the locked destination, and the public key of the oracle, which was used to create the lock
- The system creates a blank raw transaction, which has no outputs and only has one input: the locked output, spending from the locked destination
- The system requests the oracle to sign the transaction stub with
"NONE|ANYONECANPAY"
- The oracle returns the signed transaction stub (UC-Oracle-2)
- The system verifies the signed transaction and checks, whether it contains the specified data as well as a valid signature from the oracle
- The system returns the signed transaction stub
5a. The oracle refuses to sign the transaction stub, because it previously signed a transaction, spending the locked output
- The system indicates the failure
- The use-case ends
5b. The oracle refuses to sign the transaction stub, because the data provided by the seller doesn't refer to a previously generated locked destination
- The system indicates the failure
- The use-case ends
6a. The systems fails to verify the signed transaction
- The system indicates the failure
- The use-case ends
- The system generated a modifiable and expandable transaction stub, spending the locked output
- The oracle will refuse to sign any further transactions, spending the locked output