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.
HalfSometimes the
time the number of
inputinputs will be less than the number of outputs, which will delay cosigners, and
sometimes the
other half of the time the number of inputs will be 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.