CHIP-0042: Protected Single Sided Offers

[Rigidity]

No description provided.

[danieljperry]

This CHIP is now a Draft. Please leave your reviews here.

[danieljperry]

My biggest concern currently is that the offer maker has to rely on the taker to use a wallet that implements this CHIP. Is there a way to shift the burden of protecting the offer so that it doesn't fall entirely on the maker?

We should put together a Zoom call to discuss this and other questions.

[SlowestTimelord]

Nice work @Rigidity!

My biggest concern currently is that the offer maker has to rely on the taker to use a wallet that implements this CHIP.

I personally don't see this as a major concern, but rather as growing pains of almost any CHIP that wallets would need to adopt. I like @Rigidity's suggestion of mitigating the risk of proactively warning the creator of the wallet to encourage takers to use a compatible wallet.

As for the invoice solution, it sounds more like wallets using the Offer File format as a means of auto-filling details of a transaction. If that's the case, has there been thought given to a more generic schema/format that invoice creators could instead leverage? Like a manual copy/paste version of WalletConnect functionality.

[Rigidity]

My biggest concern currently is that the offer maker has to rely on the taker to use a wallet that implements this CHIP. Is there a way to shift the burden of protecting the offer so that it doesn't fall entirely on the maker?

As mentioned, pretty much all added functionality to wallets shares this same property. The alternative path would be making a completely incompatible offer standard for this, however because single sided offers are already possible in wallets today, I don't think it's worth doing. It would require additional auditing and wider ecosystem support if done that way.

[Rigidity]

As for the invoice solution, it sounds more like wallets using the Offer File format as a means of auto-filling details of a transaction. If that's the case, has there been thought given to a more generic schema/format that invoice creators could instead leverage? Like a manual copy/paste version of WalletConnect functionality.

I realize now that invoice offers as they work today can actually be secure (assuming the wallet asserts its payments correctly). So I've changed the direct payment method to a suggestion rather than requirement, and also mentioned other options are possible (though out of the scope of this CHIP).

I agree that a deep link or smaller string for invoices would make more sense from a usability perspective, though I should note that invoice offers at a Chialisp level support requesting specific memos be sent to the address as well, so you could differentiate payments with either solution.

[trgarrett]

Securely adding fees at the same time you accept the offer seems like it would accomplish the same thing. The thought there is probably that single-sided offer acceptors don't have XCH for fees, right?

[Rigidity]

Securely adding fees at the same time you accept the offer seems like it would accomplish the same thing. The thought there is probably that single-sided offer acceptors don't have XCH for fees, right?

Yeah that's a good point but one main use case here is for people who just installed the wallet and scan a QR code or NFC and don't have any assets already. The maker adds the fees for them too.

But I can update the CHIP to mention fee spends as an alternative, and implement that in Sage if the user adds a fee. Since it would save on cost.