In Episode I, we introduced bound payments and their first application: P2P exchange of one Byteball currency for another Byteball currency. Now we extend their power by allowing to bind a payment to an event that happens outside the Byteball platform.

The external events are brought into Byteball by trusted third parties — oracles — who monitor specific events and import them into Byteball database as a data feed.

Once the events are there, you can set the terms of the contract and bind your payment to the other party’s performance:

Binding payments to events introduced in version 1.6

Your money then becomes locked in a smart contract that the other party can’t spend before it performs the actions required by the contract. As soon as the required event is evidenced by the user-chosen oracle, the other party can unlock the funds. If this doesn’t happen within the specified time frame, you can take your money back.

Although the oracle is a trusted third party here, it is not a party to the deal. It needn’t be asked for permission, it needn’t know anything about your deal, you, or your peer, it just posts publicly available data and doesn’t care how this data is used. And since the data is publicly available, everybody can verify that the oracle’s data feed is true and accurate. If an oracle attempts to lie, it can lie only once.

P2P Exchange of Bytes vs. Bitcoin

The screenshots above show what a P2P trade of bitcoins against bytes (or blackbytes, or any other Byteball currency) looks like. The seller of bytes binds his payment to an event posted by an oracle whose address is FOPUBEUPBC6YLIQDLKL6EW775BMV7YOH. This oracle monitors Bitcoin blockchain and as soon as a block accrues at least two confirmations it parses the block to find all Bitcoin addresses that received a payment and the amounts they received. It then creates a record for each payment in the format “address:amount”, e.g.

1LR5xew1X13okNYKRu7qA3uN4hpRH1Tfnn:0.5

and calculates the Merkle root over all these records. The Merkle root has the size of a sha256 hash and allows to prove that each of these records is indeed included in the Merkle tree. The oracle then posts this Merkle root to Byteball database as data feed. The use of Merkle tree allows to post just hash-size data instead of the full list of the records in the 1M-size block.

The seller of bytes specifies his Bitcoin address and the amount (in BTC) he expects to receive, in the “Expected value” field of the contract (the Bitcoin address should never be reused). The buyer pays the requested Bitcoins and then he needs Merkle proof in order to unlock the bytes from the smart contract. The proof can be created by anyone from the publicly available data of Bitcoin blockchain and using the publicly known algorithm that the oracle uses to calculate Merkle roots. To assist users in unlocking their funds, this oracle also runs a bot that produces proofs for requested Bitcoin addresses:

BTC oracle can also produce proofs on request. The oracle address is byteball:A7C96Bhg4Gpb2Upw/Ky/YfGG8BKe5DjTiBuJFGAX50N1@byteball.org/bb#0000

The buyer then copies and pastes the obtained proof (just a long string of data) to unlock the funds from the smart contract:

Other P2P Contracts

Binding one’s payment to an event on Bitcoin blockchain is just one example of the power of bound payments. With the relevant oracles, it is possible to make payments conditional on other publicly known and verifiable events and enable new P2P activities. Here are a few examples:

Altcoin vs. Bytes trades bound to payments on other public blockchains. Having a number of oracles monitoring altcoin blockchains would enable a network of cross-chain P2P exchanges, something that Interledger is trying to do.

Safer online purchases by releasing the payment to the seller only after delivery is reported by an oracle run by FedEx (or another shipping company). We no longer need to use escrow or rely upon centralized intermediaries. It is still not completely safe as the seller still can send you an empty box.

Buying air tickets with protection against canceled flights. The money is locked in a smart contract and is released to the airline only after an airport oracle registers the take off of your plane. If the airline goes bust before the scheduled flight, or the flight is otherwise canceled, you take your money back.

Buying domain names without intermediaries. The money is locked in a smart contract before a registrar’s oracle evidences owner change on the domain.

Anything else you can imagine where the performance of the other party is visible from the publicly available data, can also be included in the terms of a bound payment.

This is much more than you can do with traditional — disconnected from performance — payments, and this is what makes smart P2P money great.