1. How do you prove that the cosigners were chosen randomly?
By using a
verifiable random function.
2. A typical transaction has one input and two outputs. This implies a shortage of inputs available to cosign. How do you ensure that cosigners are available for each input and inputs are available for each cosigner?
It's only typical for consumers to create transactions that split coins. Merchants typically create transactions that merge the many smaller coins created by consumer activity into one or a few large coins. That means there will be times when the number of inputs is less than the number of outputs, which will delay cosigners, and other times when the number of inputs is greater than the number of outputs, which will delay confirmations, but there will always be a natural average of 1:1.
3. An attack seems possible in which the attacker creates transactions but refuses to cosign their assigned inputs. I think this was already suggested, but your reply was not clear to me.
When a cosigner is nonresponsive, the sender must replace their address. They must redact the first or previous transaction before publishing a new one to avoid having more than one version of a transaction in the mempool at a time.