Improving Upon My Previous Example

Let’s apply this knowledge to the example from last time. As a quick reminder, here is an overview of the problem I am looking to solve:

Consider the user A who seeks to pay B,C,D for a service. If the service succeeds, B,C, and D are paid. If the service fails, only B and C are paid. B is a trusted party, capable of determining whether the service succeeds or fails.

And here is the solution from last time:

Account A

balance: 9 XLM

sequence #: 3 A constructs two transactions: TX A:

Sequence #4

Pay B 3 XLM

pay C 3 XLM

Pay D 3 XLM TX B:

Sequence #4

Pay B 3 XLM

pay C 3 XLM A signs both these transactions and gives them to B. Once the service is finished, B submits TX A or TX B depending on the success of the service.

However, note one of the major flaws I did not address in the previous example (thanks to Alexander for the comment):

Alice [A in the example above] could just issue another transaction that increases the sequence number

Unfortunately, yes she could.

So how can we lock these funds and prevent Alice from spending the money she has set aside to pay B, C, and/or D?

To do this, we will use our new tool: pre-authorized transactions.

Let’s jump right in.

Setup:

A creates an account E with her 9 XLM and sets all thresholds to 1. Account E

balance: 9 XLM

sequence #: 1

low threshold: 1

med threshold: 1

high threshold: 1 B constructs two transactions, just like A did last time, except this time B will set the sequence number to be sequence number+2: TX A:

Sequence #3

Pay B 3 XLM

pay C 3 XLM

Pay D 3 XLM TX B:

Sequence #3

Pay B 3 XLM

pay C 3 XLM A will construct a third transaction with the hashes of the transactions given to her by B: TX SETUP:

Sequence #2

Master Key weight: 0

Add TX A HASH as a signer w/ weight: 1

Add TX B HASH as a signer w/ weight: 1 A signs TX SETUP with Master Key E and submits it to the network.

Woah, woah, woah, what just happened?!?!

We now essentially have the same setup as before, but this time, the 9 XLM are locked — A has no way of accessing her funds. Even more important, since A cannot access account E, TX A and TX B are both guaranteed to be valid until one of them is spent. As a bonus, since B constructed both transactions and only sent the hashes to A, only B has the power to submit the final transaction.

As per one of the comments on pt. 1 (thanks to Xavi):

It would be interesting if you implemented time-bounds to those operations for when transaction A and transaction B can be sent by Bob (e.g. after 30 days, the house should be built).

A can construct a third transaction, TX C, that will refund her the 9 XLM if B doesn’t submit either transaction before a certain date. Here is the edited setup: