Quote from: d5000 on June 06, 2019, 05:42:41 PM

I wonder however what would be the exact use case you have in mind. Atomic swap via LN maybe (you wrote about "exchange")? Yes, that should be definitively possible.

Say I want to issue a single-use voucher code/card that can be redeemed for bitcoins, and prove:

a) That it can be claimed for its value even if I go out of business or die unexpectedly, and
b) That I can not abscond with its value.

This would be easy to do with on-chain transactions, and Casascius addressed both of these conditions in 2011 with his two-factor physical bitcoins. He issued token coins, not voucher cards, but it's the same idea. However, this is no longer feasible with low-value transactions, because of the current fee economy. Early Casascius products were sold for a couple dollars; vouchers of equal USD value issued today would be tedious to redeem, because of the transaction fees involved sometimes eating a large portion of their value.

The idea is to be able to create a low-value voucher code that can be redeemed through LN. Here's what I had in mind so far:

1. The guarantor and buyer of the voucher generate a two-factor key T, using the guarantor's code T_A and the buyer's passphrase T_B, with a scheme akin to casascius.com/2factor
2. The guarantor generates a "revocation key" R
3. The guarantor sells the buyer a physical card with the voucher code covered by a tamper-evident security hologram
4. The buyer confirms receipt of the card and the guarantor funds a 2-of-2 multisig script (using the pubkeys of T and R) with the value of the card; the fee to fund this script is a part of the card's premium (Hopefully with Schnorr signatures to reduce the size of the script and redeem script)

Now assume some time has passed and the buyer (or whoever now owns the card and T_B) would like to redeem the value of the card with LN, and the guarantor still exists:

5. The buyer removes the security hologram and accesses T_A, and combines it with T_B to generate T
6. The buyer signs a message to prove that they have T; the guarantor still has the pubkey of T
7. The buyer generates a lightning invoice using T as the secret; the guarantor pays the invoice and thus receives T (the voucher has been redeemed)
8. The guarantor uses T and R to collect the value of the card from the multisig address, paying a low fee and letting it confirm eventually

Alternatively, the buyer could choose to redeem with an on-chain transaction instead, for some reason, while the guarantor still exists:

5. The buyer removes the security hologram and accesses T_A, and combines it with T_B to generate T
6. The buyer signs a message with T, declaring that they are not interested in a lightning payment
7. The guarantor sends R to the buyer, permanently revoking the buyer's right to claim the voucher with a lightning payment
8. The buyer uses T and R to collect the value of the card from the multisig address (the voucher has been redeemed, but maybe with a large fee)

And if the guarantor does not exist anymore, for whatever reason, a lightning payment will not be possible:

5. The guarantor has failed, and publishes R (or in case of death, perhaps using a will or dead man's switch)
6. The buyer removes the security hologram and accesses T_A, and combines it with T_B to generate T
7. The buyer uses T and R to collect the value of the card from the multisig address (the voucher has been redeemed, but maybe with a large fee)

The guarantor can not have T until they have paid the value of the voucher in full to its owner. So the card can not be invalidated to the benefit of the guarantor. There are still some ways that the card could be made void:

The card is destroyed, and thus T_A is lost
The buyer had bad data storage practices and lost T_B
The guarantor made a mistake and did not include T_A on the card
The guarantor had bad data storage practices and lost R; if they instead lose the public key for T but can still publish R the card can still be redeemed by its owner with an on-chain transaction
The guarantor shut down or died, but R was unable to be published

That may look like a long list, but if the guarantor is competent it should not run into these problems (though we have seen incompetent issuers of physical bitcoins before). The buyer can take care by keeping the card safe, and by keeping T_B near or on the card itself. By putting virtually indisputable bitcoin value on a physical object of low enough value to just give away as a gift, you have created something to get people interested in bitcoin. You can see testaments to the power of just putting something in people's hands by reading the early replies to the Casascius coins thread. Physical bitcoins no longer have this utility, and have over time instead become more of a collectible item for people that are already very, very interested in bitcoin. It is just not economical to create low-value pieces, even in base metals like brass or aluminum. We know this is the case because nobody is doing it anymore. Well, either that or it is actually just a stupid idea in general. But I don't think that is the case, because people still fund high-denomination pieces.

This would probably not be economical for the guarantor of voucher cards in this situation either, especially after jumping through legal hoops. But the guarantor is very interested in getting bitcoin into more people's hands.