co-spend proposal parameters #75

as part of specifying the various protocol messages, one thing i wanted to solicit input on was the constraints on transactions and how to design them

this implicitly forms a join semi-lattice, but we are more concerned with the meet, if one exists, the intersection of the valid ranges.

• feerate - numeric interval
• nlocktime - numeric interval
• version - numeric interval
• allows input & outputs types
  • lower bound: the final set must be a superset of the specified set (ensuring that the input types parties wish to spend or output types they wish to create are allowed)
  • upper bound: the final set must be a subset of the specified set (ensuring that forbidden input types, e.g. legacy inputs are excluded for stable txids)
  • presumably types should just be an enumeration of different types, including one "other"
• maximum transaction weight - upper bound only (allow non-standard? specify in vbytes?)
  • weight allocation per initial input is this value divided by number of initial inputs
• minimum input count - take the max
• allowed input values - numerical interval
• required input values - set bound on the nominal values - can be used to ensure that specific standard denominations appear in the input set
• sumset lower bound bound (subset sum density certificates)
  • works like a randomizable set bound
  • the aggregator must demonstratethat the sumset generated by the effective values of the input at its chosen feerate has at least $\rho$ values in some interval of a chosen width $w$, where the interval is centered at the value $b + c*H$ where $b$ where $H$ is a hash of the coalition formation proposal interpreted as a value $\in [0,1]$ and $b$ is a base offset determining the start of the interval.
  • a certificate is just a $\rho$ sized list of input indices, the aggregator must solve for these for a coalition formation proposal to be valid

here are some examples of proposals that make should be expressible. the overall goal is that for every one of these scenarios, if the user (or really the cost function) indicates that a particular batch or outcome is bad unless a certain condition holds (particularly subset sum density related privacy liabilities), co-spend proposals that ensure a minimally favorable outcome but create possibilities for even more favorable ones are expressible

• solo taker: just one input, with a surplus, and conditions. such proposals are analogous to taker orders submiitted for matching.
• solo maker: same, negative surplus requests a fee from all parties
• joint makers: group of similar or complementary valued coins offered together, in particular a sub-coalition of "lucky" (per randomization term) makers can collectively bargain
• anonymous taker: several inputs, one of which is the taker's either similar coins or complementary
• borromean ring inspired structure: a subset of the taker's coin selection can independently participate in co-spend proposals that are complementary
  • this also allows loosening bounds by relying on the intersection of the co-spend proposals constraining the acceptable range (still reveals some preferences through acceptance of coalition formation proposals)