Open-Transactions and Bitmessage combination to produce: SERVER-TO-SERVER WIRING PROTOCOL An easy way for OT wallets, behind the scenes, to negotiate server-to-server transfers of funds. Let's say Alice is someone who wants to transfer Silver Grams from Server A to Server B. Let's say that Bob is someone who is willing to perform such transfers for a fee. 1. Alice forms this string: "Silver_Asset_ID+Server_A_ID+Server_B_ID" 2. Alice uses the above string to generate a Bitmessage broadcast key (Bitmessage calls this a "pseudo-mailing-list.") 3. Bob, wishing to earn some money, is already listening to all broadcasts for that key. 4. Alice broadcasts a message to that key: "I want to transfer 100 grams from A to B at price of 1 gram. My Bitmessage ID is ALICE." 5. Bob receives the message, and agrees with the price. He sends a message via Bitmessage to ALICE, saying, "I am willing to make the transfer. My NymID on both servers is BOB. My silver account on server A is BOB_A and my silver account on server B is BOB_B." 6. Alice initiates a Wire via Escrow (a smart contract we will make), from her account on Server A, to Bob's account on Server A, in the amount of 101 silver grams. This smart contract then sets a timer for 1 to 5 minutes. 7. Alice sends a Bitmessage (or OT message, either will work at this point) to Bob containing the transaction number of her running smart contract on Server A. 8. Bob initiates a Receive Wire via Escrow (smart contract), from his account on Server B, to Alice's account on Server B, in the amount of 100 silver grams. This smart contract contains Alice's transaction number and sets a timer for 10 or 15 minutes. 9. After Server A's timer activates (1 to 5 minutes, say--or less) Server A notices Server B of Alice's escrow wire initiation, either directly (via Server B's public key and IP address in the its server contract) or via Bitmessage (via Server B's Bitmessage address from its server contract.) FYI, either way, Alice can directly supply the contract for Server B when she initiates the Server Transfer via Escrow at Server A, since contracts on OT are self-verifying. (Meaning that Server A doesn't even have to be aware of Server B, prior to this wire.) 10. When Server B receives Server A's notice, it is able to verify it using Server A's contract. It then searches for Bob's Receive Wire escrow, which it finds (based on Alice's transaction number), and thus it releases the funds from the Escrow on Server B to Alice's account on Server B. 11. Server B can then notice Server A to release the funds on its side. Bob, wishing to insure payment, also has the ability to directly notice Server A, with his payment receipt (from the Escrow smart contract) being furnished as proof.