Address Private Comments #1
Description
Special thanks to quexington for reviewing this code before the CHIP. This issue documents design concerns (and my answers to them) outlined here and in private discussions.
Concern: Announcement assertion is not plugin-able (e.g., you can't have '1 asset for 2 assets' partial offers).
Answer: After talking to Rigidity/Andreas, we'll stick to one-asset-for-one asset for this version of partial offers, as that simplifies the puzzles a lot.
Concern: the notarized payment format is (nonce . ((ph amt ...) ...))
Answer: I was also very confused that the code works once you pointed this out; credits to Brandon for saying that (c nonce (list payment)) is equivalent to as (list nonce payment) multiple times until I got it.
Concern: Assuming a memo format could be dangerous for future extensibility
Answer: Not assuming it means potentially storing the hint again, which increases cost. We'll stick with this for now, as the royalties payment program does.
Concern: Why not just curry in the inner puzzle hash? / You can assume an honest setup presumably based on the rest of the curried arguments / parent and amount can be asserted via their own conditions / and you can lose the coin ID calculation and the CAT_MAKER entirely.
Answer: This is an interesting idea. Essentially, you can set the puzzle's 'next puzzle hash' to the maker's puzzle hash - let's call it puzzle hash A. Then you can compute puzzle hash B = partial offer inner puzzle hash with the next puzzle hash = A. You can build a chain during setup, with the next puzzle hash going ... -> D -> C -> B -> A. The reason I don't think this is appropriate here is because this method is a bit hacky and creates two new concerns:
- Computational requirements: makers/takers would probably need to run hundreds/thousands of curries for each creation/acceptance.
- Partial offer DOS: Someone might just 'run through' all layers and cancel someone else's partial offer. To avoid, you'd curry more and more times - but that means more computations for the parties involved (or a lot of hints).
For now, the CAT maker remains a necessary evil in the partial offer spec.
Concern: Like could someone end up getting a better deal than they should by taking advantage of some 1.9 == 1 shenanigans?
Answer: The puzzle is rounding the computed down, favoring the maker.
Concern: So why bother with the extra create coin here whos amount I think can only be zero? (...) I think I still might prefer a deliberate send to the offer puzzle for what it's worth. Since that's always what you expect it to be used for, there's no need, and only fear of arbitrary flexibility here.
Answer: The coin creation is there to avoid the taker having to absorb the value using a CAT they already own (in the trading configurations where the taker would receive a CAT). The amount is now checked (> -1), but we'll keep arbitrary puzzle hash/memos.
Concern: consider a complaint lodged against multiple offer file formats coexisting / But yeah I think of the options I'd prefer that it's a regular offer with a spend path to make it land in the partial state if so desired. And then those partial things are discovered independently of files being shared about them.
Answer: Wallets/bulletin boards will need to support custom code to support partial offers in either case. partial1... is a good prefix as it immediately signals the offer is using another standard. That allows using a custom hint, which makes partial offers extremely short (well, at least after the first coin is created on-chain - the first partial offer will contain coin spends to make that happen besides the small hint).