Quote from: d5000 on June 07, 2019, 07:34:12 PM

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.

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.

Quote from: d5000 on June 07, 2019, 07:34:12 PM

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 am overlooking 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 are 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. Have to think a bit about that ...)

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.