atomic file swaps

never mind, just use 2-2 multisig with some collateral put in by provider and more by payer, both lose if both aren't happy

by not grabbing rebate, A can avoid paying in old design

Let's say A read on a forum that a file that has a specific public hash of a hash "H(H())" is really good and wants to buy it
(to compensate for bandwidth used or for content itself, same thing).
B claims to have the file to match that H(H())

# [b]Issue[/b]:

A can't just pay first because B can just not deliver file.
B can't just send file first because A can never pay and bandwidth ain't free.

# [b]Solution[/b]:

H() = hashing function, e.g. SHA256 like in OP_SHA256
<A priv> = A's private key
<B pub> = B's public key

B commits to delivery of file matching H(H(file)) on blockchain w/ locked rebate for X days to act as deterrent for sybil false claims.
A locks payment to B in contract that requires A to claim the rebate
A has incentive to claim rebate once A has the file
Claiming rebate reveals A's secret which lets B get paid

<A priv> has H(H(file)), <B pub>, and secret.
<B priv> has file, <A pub>, and H(secret)
Alloted time for trade is X days
Commitment to deliver is Y coins locked up by B
File price is Z-Y coins

B stores rebate in tx1
output type: p2sh (pay to script hash)
value: Y coins
output unlock requires: "rebate"[sig match <A pub>,  H(file) match H(H(file)), secret match H(secret)] or "refund"[over X time has passed, sig match <B pub>]

A stores payment in tx2
value: Z coins
output unlock requires: "payment"[sig match <B pub>, secret match H(secret)] or "refund"[over X time has passed, sig match <A pub>]

# [b]Effect[/b]:

- hash match guarantees the file is exact same as publicly reviewed file
- B cannot spend tx2 without knowing A's secret
- A cannot spend tx1 without knowing H(file)
- A claiming rebate lets B get paid
- If either doesn't like something, both can wait out X time and get money back
- If A never claims rebate after getting file, B gets paid Z instead of Z-Y
- B providing just H(file) to A doesn't break anything since entire point is A wants to get it
- Even H(file) leaking to A not big deal since A grabbing "refund" reveals secret so B can grab a larger "payment" or wastes time of both

Only when A knows secret and file can A get Y coins back, but reveals secret to B in process (net sum = -Z+Y coins)
B can use that secret to take the payment of 2 coins (net sum = +1 coin)
If B simply reveals H(file) and not file, A has no reason to claim 1 coin when they would lose 2 and would just wait it out
If file never provided, each output has additional condition to allow withdrawal after X time.

Q1: how to avoid using off-chain communication? like avoiding <B pub> in rebate so address to monitor for commits is predictable for A instead of relying on off chain communication?
- Could add second output with OP_RETURN <B pub>. A could monitor tx w/ OP_RETURN H(H(file)) <B pub> and then be able to verify B in fact used the right p2sh script. A's request for file could also be done with OP_RETURN by providing a marker like "filereq", H(H(file)) of file A wants, X, Y, and Z.

Q2: subatomic swaps for files make this useless? merkle tree of file data with root used for identification. can pay for fragments of files with inclusion proofs that it's correct so never risk entire payment and can use lightning network. if content fragments are in sequence, would work on paying for streaming real time. downside is public communication is difficult to signal request or providers and can lose a little on a single payment vs losing it on neutral fees on-chain.

good idea? bad idea? wrong forum for this discussion? been wondering why not use files as secrets in atomic swaps, but since files are too big for blockchains, hash of file works similar.