Using OP_CHECKLOCKTIMEVERIFY for offline transactions - possible?

[d5000]

In the Spanish forum, I stumbled upon a question if a safe transaction in an area without stable Internet connection was possible.

In my opinion, the following mechanism should work, loosely based on the mechanism for Atomic Cross chain trades.

Let's have Bob (B) that wants to sell a good for Bitcoin to Alice (A). They have internet access at least once per week, but the transaction must happen in a rural area without internet access. Bob owns a mobile electronic device that can prove that a hash is correct.

1) Alice sends Bob two signed transactions that contain the following outputs (like in TierNolan's example for XCATs):
-  TX 1: "Pay w BTC to <B's public key> if (x for H(x) known and signed by B) or (signed by A & B)" (in short: Alice sends Bob a hash of a secret x. If Bob knows x, then he can move the money from his address)
-  TX 2: "Pay w BTC from TX1 to <A's public key>, locked 7 days in the future, signed by A" (in short: if in 7 days Bob hasn't provided the secret, then the money is returned to his address)
 
2) Bob verifies that both transactions are valid and stores the hash H on his mobile device.
3) Bob and Alice meet in the area without Internet connection. Bob presents the good to Alice. If Alice wants to buy it, then she gives Bob a pendrive or paper containing the secret x. Bob checks the hash on the electronic device (or on paper, if he's good at math ).
4) So at the end we have 2 possibilities:
- a) Alice bought the good. Bob releases the transaction the next time he gets Internet access with the secret he got.
- b) Alice didn't buy the good. The money is returned to her after 7 days.

Did I overlook something? Maybe the mechanism is already known (or even in use), but I have googled a bit but didn't find it.

[Taras]

This reminds me of "Trustless Payments for Publishing Data", a section of BIP 65, where in this case the "data" is the key that A gave B (aka x) in return for the good. Basically A buys x back from B, and if B never shares x within a time limit, which would be the case if the item was not sold in the first place, then A can reclaim the money (at any time in the future beyond that point).

H(x) would correspond to Hash160(encryption key) in the example in the linked document. So basically x becomes a provable "voucher code" that can be redeemed by the intended recipient only for the amount of bitcoins in the output (before it expires).

I am not sure if a transaction of this type would be considered to be standard, but probably not. (It would still be valid, though.)

Edit: If B has a laptop, he can verify H(x) matches the data in the transaction using an offline web app or program that calculates hashes. H can be sha256, ripemd160, sha1, anything bitcoin script supports; and whatever A chooses.

[d5000]

Thank you for pointing me to that use case! Yes, it looks very similar to the off-line payment concept I described, although it seems to use one transaction that contains two possible outcomes (via if/else).

I think then that it basically should work, as long as miners accept the transaction. It would be interesting if this concept has been applied somewhere already.

Of course Bob needs a device to check the hash/the correct "secret". However, also in rural areas of third-world-countries - the region where I see potential for this kind of payment, because internet connection there is often very unstable - smartphone penetration is growing, and even cheap "feature phones" now often feature the possibility to install apps, so the hash check should be not a big problem.