spec: remove funding confirmations requirement

[buck54321]

Drops the minimum funding confirmations requirement.

1. Confirmation requirements for funding outputs add no real security and some major programming and UX issues.
2. The user is required to lock up more funds than they are trading if their order doesn't match immediately, since transaction outputs can't be sized at trade time. Solutions such as pre-splitting transactions to lot-sized or multi-lot-sized outputs is possible, but would increase realized transaction fees, make small lot sizes infeasible even for low-tx-fee-rate assets, and still delays the users ability to trade after funding their exchange wallet.
3. The funding confirmation requirement also requires a lot of special handling of outputs, such as the change output monitoring for the client and special handling likely requiring deep DB scans for
   the server.

For these reasons, dropping the confirmation requirement is proposed here.

There are some possibly valid counter-arguments to this proposal. Please try to keep most discussion here on github for documentation and transparency.

[chappjc]

This summarizes our discussion on Matrix fairly well. Starting at https://matrix.to/#/!EzTSRQITaqHuFBDFhM:decred.org/$rvpuvOY1n0uK0PBFp7IBijwhoV3IVHw6Ly7OUTzF1JM?via=decred.org&via=matrix.org&via=planetdecred.org

I will raise here one concern that I mentioned in chat, which is the possibility for the client to select unconfirmed utxos to fund orders, where these utxos were created by untrusted parties that may attempt to double spend the source coins. If such a double spend happens after the user has placed the order, this would result in the split tx that funded the order becoming invalidated, thus defunding the order.

Since swap confirmations is still a requirement, there is no risk of funds being lost, just the user being penalized if they are unable to create the swap contract txn, or if the swap contract txn becomes invalidated itself.

I can only see this being a risk if applied on a large scale, targeting a significant proportion of dex user wallets in the hopes of causing a notable proportion of DEX orders to fail at swap time. It's impact is also greatest if the taker is attacked because the maker will have already broadcasted their contract and they will have to wait up to the maker swap time to refund, which could be as long as 48 hrs. The potential impact can be mitigated by clients preferring confirmed outputs.

Implementation of funding confirmation requirement removal is in #499

[chappjc]

Changes look good. Leaving open for discussion.

[JoeGruffins]

I think that preferring "trusted" outputs is a much better solution to the problem of double-spends. It can be the wallet software's job to tell us what is trusted.