Discuss fee options in protocol document

[nothingmuch]

• Client calculation network & coordinator fees and account in balance proof
• Coordinator adjustment of credential amounts

[nothingmuch]

after transaction structure we will probably have to revisit this if the coordinator provides incentives for certain outputs. for example, a policy i have in mind is to allow 0 mixing fees for sufficiently old, low hamming weight outputs of distinct previous coinjoins by the same coordinator, effectively letting users remix for free but only if they've aged their mixed outputs enough. it's not clear to me if it's better to make that be a static policy or done by adjustments. also note that the coordinator can pre-announce any adjustment at input registration instead of waiting until the last connection confirmation to reveal the adjustment, thus avoiding the need to tweak the requests.

[nothingmuch]

note that this does not cover #18, which would require a more complex design:

• long lived fee-only credentials (can just be wabisabi credentials with per epoch issuer parameters)
• additional presentation and change request with these fee credentials in every request
• instead of one balance term, there are two, one for the nominal amount and one for fees paid (both network and coordinator fees)
• input amounts can be converted to fee amounts but not vice versa
• fee credentials are not actually issued until after the round fails or the coinjoin tx is confirmed. after failure, presented credentials can be refunded in exchange for new ones. on success change requests previously validated by balance proofs can be issued.
• fee reissuance command for consolidation and epoch migration (older tokens expire to keep server state bounded)
• the coordinator would cover mining fees by providing inputs, which it can do as part of consolidation of previous transactions' fees

such a design would allow small amounts of change to be converted to prepaid fee tokens