Editing Atomic cloud storage (section)

= The audit contract =

The above contract enforces payments for downloads but what is still missing is a way to enforce storage - the farmer should be paid to store content irrespective of whether the renter decides to download anything since its still taking up space on their drive. One way to do this is to pre-generate a series of hash-based challenges [0].

Essentially, the renter would generate a table of random numbers and record what the result of hashing them was with the data to be stored. To pass the audit the farmer would have to provide a valid hash for a given challenge which would then prove that they still have the content. Payment could then be made from the renter or a third-party based on the audit results - but I’m trying to do this in a way where being paid is guaranteed for passing an audit irrespective of any action from anyone [20].

To accomplish this goal - I’m going to create a TX that requires a partial piece of the file to be revealed to claim a coin (using OP_HASH160 and OP_EQUAL [21] [22].) These TXs will occur every N minutes using ntime-locks so that multiple previous audits may be confirmed in a single block.

Every given interval will thus correspond to a new audit and the audits will all be random so the farmer can’t choose a subset of file contents to pass all the audits without storing the full file – it becomes statically unlikely. But how to do this? There’s no OP_RANDOM in Bitcoin … fortunately - the TX confirmation on double spends are notoriously random in Bitcoin.

<span id="the-audit-contract-works-like-this"></span>
== The audit contract works like this: ==

# TX1 funds a number of outputs corresponding to an audit.
# Multiple hash-locked transactions are generated for each output which ''double spends'' from the same output.
# Both the farmer and renter can broadcast any of these double spends at any time and the network will race to confirm one of them.
# Another transaction is generated for each audit TX that basically says: I am going to double spend this audit transaction and all future audit outputs after a given time frame. (Its a refund that’s valid after an audit fails.)
[[File:2.png|thumb]]

In the traditional scheme only the renter is responsible for defining the audit conditions. This means that the renter can theoretically define a series of payments for a given hash that in reality don’t correspond to the hash-based challenge for a file audit at all. In English, the renter could cheat the farmer out of payments for a valid audit as everything relies on trusting the farmer. My scheme solves this problem by making the audits bi-directional.

Both renter and farmer are defining what constitutes a valid audit by progressively defining a series of double-spends for each audit. Neither party knows what will actually be confirmed by the network – its a race condition that becomes statistically unlikely for either party to predict it over time yet the farmer is guaranteed to be paid if they can pass the audit.

The protocol for this is fairly simple. The renter and the farmer keep swapping signatures for the audit double spend TXs until every transaction in the series has been created. The protocol starts out by asking the farmer to sign an audit double-spend TX and give the signature to the renter. At this point the renter has at least one valid transaction for doing the first audit so they know that the farmer at least intends to keep that part of the file.

The renter then exchanges their signature for that TX so the farmer knows that at least they will get paid for keeping that part of the file. The scheme continues like that for the first audit until there are numerous possibilities for the first audit. They then repeat this process for the remaining audits until both sides end up with a list of transactions they can try submit to the network, meaning that neither side knows what will be confirmed.

This means that in essence – the farmer has to keep the whole file around for it to be statistically likely that they will be able to pass all audits as neither side knows what audit will be confirmed. The renter and farmer can now randomly select one double-spend TX to keep for each audit and throw the rest away. The audits could even be given out to a third-party without having to trust anyone someone with any actual money - awesome [23].

<span id="economic-attacks"></span>