Topic: Zero knowledge contingent payments on the Lightning Network (Read 308 times)

R protects the guarantor from a dishonest buyer. If the guarantor kept their copy of T_A and accepted T_B as the secret. the buyer could accept a lightning redemption, at which point the guarantor will use T to spend the multisig commitment (which in this case could be T_A and T_B instead of T and R). However, the guarantor doesn't care if this transaction takes a long time and wants to include a low fee. The buyer in this situation would also have the right to spend the commitment, even after collecting the lightning money, because they too have T. They can include a higher fee than the guarantor, since they have already gotten the full value of the voucher over lightning anyway, so they can take the on-chain commitment after already accepting the lightning redemption. Taking from the guarantor double the value of the voucher.

I believe there are good precautions the guarantor can take to ensure that R is published after they close down. They can send an encrypted list of every R for each voucher issued to several trusted escrows, which can be decrypted with a majority of their keys. If the escrows should find that the guarantor has died, or cannot continue for legal reasons, or became evil or whatever, they can publish R themselves.


The thing to remember also is, the buyer might not know the first thing about bitcoin. They might have just used a tool on the guarantor's website to agree on T, they might be using an SPV lightning web wallet to redeem this. And the person who redeems the voucher may not be the same person as the buyer. Transferring ownership should be as easy as placing the voucher and T_B (probably on the same card) into someone's hands, and that guy you saw at McDonald's the other day had better be able to figure out how to use it. If they have to operate a specific pre-existing lightning channel, it may be a little stressful to figure out how to buy their first coffee with their new bitcoins.

I don't like it, but it's looking like it may be necessary for the guarantor to offer a less-provably-trustworthy method of redeeming the voucher using a lightning payment, by just taking from the owner T_A and T_B and the LN invoice off Bitlum with a web form or something, and then the owner has to trust that the guarantor will make good and send the LN payment. Or someone with c-lightning could do it the right way by using T as the secret, because they know their way around the software and don't need to exchange trustworthiness for ease-of-use (that is, if c-lightning or some other software now or will ever support specifying the secret). You could also abolish T_B if you trust the issuer - the vast majority of Casascius coins and other physical bitcoins use only T_A, because the issuers are trusted to destroy their copy of T_A after putting it on their product - but maybe T_B can be made user-friendly enough to where that would not be necessary. After all, the only requirement for T_B to make sense is that the guarantor must not see it. T_B could be a simple pass phrase.

Ideally, the owner would never, ever have to use T and R to claim the bitcoins on-chain, unless they really wanted to. But the option's there and can probably be made simple enough if bad things happened.

The idea sounds interesting and it should work without problems with Lightning, as far as I know. The only thing I don't know if a full private key (T) wouldn't be too long enough to work as a secret for LN implementations.

I was however wondering why R is necessary. It doesn't allow the guarantor to run away with the money because he doesn't know T_B. But the problem that the coin/voucher could lose value if the guarantor doesn't exist anymore and fails to publish it is pretty severe in my opinion.

So what I would do instead: The voucher provides access to a simple funded Lightning channel - that would mean, that instead of using T and R for the multisig transaction, one would use T_A and T_B. The guarantor, in this case, wouldn't have to interfere anymore once he sold the coin - if the buyer wants to redeem the coins with an offchain transaction, or the guarantor goes offline (and thus, cannot receive and route LN payments from the buyer), he simply closes the LN channel as he has access to both keys once he reads T_A destroying the hologram.

Maybe I overlooked something important, however.

Edit: I think I definitively overlooked something: the problem with the setup I proposed here is that the LN channel in this case wouldn't really have a "counterparty" as both keys can be controlled by the buyer once he opens the hologram. So there is no connection to the rest of LN because the guarantor doesn't control any key exclusively, and thus would never allow payments leaving the channel, because the buyer could "refill" it itself.

So unfortunately it seems R is necessary, and thus we would have a "miminal trust" solution.

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.

AFAIK you can use any secret you want. However, very likely you'll have to use a custom implementation (or manually enter the script) for your transaction(s), as LN software will generate secrets automatically.

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.

Can we configure the payment to use any secret of our choosing? Such that it could be generated months or years before the payment takes place? Provided the payer gets the hash of the secret at the time it is generated.

What you describe is basically what an HTLC is in Lightning. HTLCs are used for the forwarding of payments and they work by the payee providing the payer the hash of a secret and then that secret propagates up the chain of LN nodes until it reaches the payer at which point the payer is guaranteed to have paid the payee.

I was wondering if it is now or will soon be possible to make a Lightning payment through which the payee discloses an arbitrary secret to the payer, provided the payer has a hash of the secret beforehand and can only get the secret when the payee is paid. The payee must not be able to withhold the secret if they are paid. I'd like to hear if anyone knows of a way to make an exchange like this using Lightning, or if this is really only feasible with an on-chain script?