Propose co spends

[arminsabouri]

All order book entries are considered atm. Takers will want to be selective and assign a payoff to each order book entry. At somepoint the cospend will be "good enough" (this will vary by wallet preference). Makers will register their input. The cost should consider their current payment obligation's deadlines.

In this current state the taker will prefer orderbook inputs that are closer in magnitude to its own inputs that it picked. I think we are missing two angles here:

• Takers run BNB and then consider orderbook utxos. But they could pick other utxos that BNB would not select that would be "closer" to the a subset of order utxos.
• Maybe there are no good order book utxos. The cost needs to be considered and if its high enough the take should then prefer a unilateral batch.

other todos (maybe for future Prs):

• change decomposition
• counter party payoffs (how much does a taker prefer a orderbook utxo -- privacy budget)
• ensuring monotonic decreasing cost as information is learned. Given the inputs in the cost spend and my own decomposition, I should be happy with subset sum density. And new information (output registration) should not worsen subset sum desnsity. TBD

[0xZaddyy]

Everything is looking good right now, just few things we might consider adding:
in the cospend.rs file, the generate_candidates function assumes all entries are valid

• i think adding a filter to check for spent/invalid UTXOs before scoring will be necesaary.
• also a check for duplicates if a UTXO appears multiple times in order book.

The taker/maker separation is clean and the scoring logic makes sense.

[arminsabouri]

went thru a messy rebase bc of #14 . will look thru history and clean it up again