Atomic exchange transactions

Question

I am trying to correlate what is written in the whitepaper (https://www.multichain.com/download/MultiChain-White-Paper.pdf) with the paragraph "Simple atomic exchange" (https://www.multichain.com/developers/atomic-exchange-transactions).

 

Whitepaper (A):

1. Alice and Bob discover each other’s mutual willingness to perform the exchange through some off­blockchain process, and agree on the transaction outputs they will use.
2. Alice’s node constructs the full transaction and signs it.
3. Alice transmits the partially signed transaction to Bob via another off­blockchain process, since this incomplete transaction will not be accepted by the network.
4. Bob receives the transaction and verifies that it accords with their agreement. If so, his node signs the transaction as well. At this point the transaction is valid.
5. Bob’s node transmits the fully signed transaction to the network which verifies it and confirms it on the blockchain.

Whitepaper (B):

A future version of MultiChain will streamline this process by enabling partial transactions to be directly propagated across the network.

Question 1: (B) has not been implemented, right? So when server 2 runs createrawexchange <address> 0 '{"USD":100}' and gets a hex blob back, server 2 has to send this blob off-chain to server 1 as in step 3 of (A) and other nodes will not know about it?

Questions 2: The hex blob in encrypted with server 2's private key?

Question 3: Anyone who knows the hex blob can accept it?

Question 4: How is the hex blob actually encoded / How can I decode it myself without decoderawexchange?

Question 5: When running createrawexchange, how to make sure that only a specific address can accept it? I thought about adding metadata in combination with a smart filter, but the documentation (https://www.multichain.com/developers/json-rpc-api/) mentions metadata only for completerawexchange but not for createrawexchange.

 

 

Answer 1

Thanks, to answer your questions:

1. We didn't implement a specific mechanism for distributed an exchange offer, but streams can very easily be used for this purpose. If you publish the data off-chain, there will only be a minimal amount of space taken up on the blockchain itself. But the offer will be visible to everyone.

2. You could encrypt the hex blob for the offer if you want to, but this would be outside of MultiChain's responsibility. (And you would use a public key of the recipient.) You could also use read-permissions streams (requires MultiChain Enterprise) to make the offer only visible to certain parties.

3. If you use a normal offer of exchanges, yes anyone can accept it.

4. The blob is a partially signed partial transaction, in the usual transaction format. So if you know how to read MultiChain transactions (which are formatted as bitcoin transactions with extensions) you can read it.

5. The simplest way to make an exchange for a specific address is not to use createrawexchange but rather the following process on the side making the offer:

• preparelockunspent to put the asset quantity on offer in a single UTXO.
• createrawtransaction to create a transaction which takes that UTXO as its single input, and has two outputs: One sending the offered asset quantity to the other side's address, and one sending the desired asset quantity to your address. This transaction is currently unbalanced so cannot yet be accepted by the network.
• signrawtransaction to sign that transaction with the last parameter sighashtype set to ALL|ANYONECANPAY which signs (i.e. locks) your input and all outputs but allow additional inputs to be added.
• Send that signed transaction to the other side however you like.
• The other side can examine the transaction using decoderawtransaction to see what is going on, i.e. what outputs are going to which addresses.
• If they are happy, they can call preparelockunspent to put their asset quantity in a single transaction output, then use appendrawtransaction to add that UTXO to the transaction they received from you, with the last parameter action set to send to sign and send it in the same step.