Editing Atomic cloud storage (section)

== Zero-knowledge proofs to the rescue ==

In Bitcoin, the transaction isn’t signed directly – only the hash of the inputs and outputs based on the SIGHASH settings. This is the key to this protocol. Here’s what’s going to happen. The farmer is going to construct a special transaction template containing their signatures but they are only going to reveal part of the transaction – specifically – they are going to reveal everything except the second half of their signatures [14].

Now what the renter does with this knowledge is create a zero-knowledge SHA 256 proof for the transaction ID (preimage since its double SHA256 hashed) that asserts that a given SHA 256 resulted from using that partial transaction. The preimage for the hash is only partial – the renter doesn’t know the second half of the signature – they only care that the farmer has reused the same R value for two signatures in the same transaction.

Thus - if the farmer can prove that a given hash satisfies these constraints - the renter and the farmer can proceeded with the protocol to create the download contract without either party cheating the other.

Ah yes … but then what’s to stop the farmer from simply changing their signatures after the renter signs, you ask? Well, did I mention the transaction goes to an output that requires the signature of both farmer and renter to redeem – and that further – this requires that the TXID for the transaction containing the weak signatures not to be mutated?

And that previously – the outputs that the weak signature transaction are redeeming requires that the signatures be valid? This is how you force someone to reveal private keys as part of a smart contract scheme without doing anything crazy like producing a zero-knowledge proof validating an entire ECDSA key-generation process (my original idea.)
[[File:1.png|thumb]]
# The renter creates a new transaction TX1 that can be claimed by either: A 3 of 3 multi-sig address OR a time-locked output + the renter’s signature (refund fail-safe.) The multi-signature uses the same public key twice that the farmer previous generated and one of the renters – meaning the farmer must give two signatures to redeem the outputs.
# The farmer generates TX2 that spends the outputs of TX1 to another multi-signature address controlled by the renter and the farmer. This multi-signature address uses totally different ECDSA key pairs to what has been previously generated. (TX2 can also be redeemed after the contract expires by the renter in case the farmer only partially completes the protocol.)
# The farmer signs TX2 using duplicate R values for the signature but ''does not'' reveal the transaction content to the renter.
# The renter signs TX2 and gives the signature to the farmer.
# The farmer now has a complete copy of TX2 and could broadcast it if they wanted. However they don’t since they don’t currently have the renter’s signature for TX3 (which would guarantee payment back to them.) Instead, the farmer reveals the SHA 256 hash of the full serialized transaction + the R value used for both signatures. ''Note: This is not a double SHA 256 hash – just the result of hashing the full serialized transaction once.''
# The renter generates a zero-knowledge key pair [15] that validates the serialized transaction format. The proof assets that the weak ECDSA signatures were used in the serialized transaction that resulted in the given SHA 256 hash. The renter gives the proving pair to the farmer.
# The farmer produces a zero-knowledge proof for their SHA 256 hash and gives it to the renter.
# The renter validates the proof – if the proof is valid - the renter SHA 256 hashes the hash to produce a TXID. The TXID is used as the input for TX3 which the renter signs, giving the signature to the farmer.
# The farmer validates the signature. If it’s correct – the farmer now has enough information to generate a valid TX3.
# The farmer broadcasts TX2 which outputs to TX3. When TX2 is confirmed, TX3 will allow the farmer to claim there money. Note: that the process of releasing TX2 gives the renter all the information necessary to decrypt their file.

<span id="generating-zero-knowledge-proofs"></span>