On Tue, Nov 24, 2015 at 12:34 PM, Chris Priest via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
The technical reason for this is that you have to explicitly list each
UTXO individually when making bitcoin transactions. There is no way to
say "all the utxos". This post describes a way to achieve this. I'm
not yet a bitcoin master, so there are parts of this proposal that I
have not yet figured out entirely, but I'm sure other people who know
more could help out.

So every input has:
 32-byte hash (transaction being spent)
 4-byte output (output being spent)
 4-byte sequence number
... plus the scriptSig. Which is as small as about 73 bytes if you're spending a raw OP_CHECKSIG (which you can't do as a bitcoin address, but could via the BIP70 payment protocol), and which is at least two serialized bytes.

Best case for any scheme to coalesce scriptSigs would to somehow make all-but-the-first scriptSig zero-length, so the inputs would be 42 bytes instead of 40+73 bytes -- the coalesce transaction would be about one-third the size, so instead of paying (say) $1 in transaction fees you'd pay 37 cents.

That's in the gray are of the "worth doing" threshold-- if it was a 10x improvement (pay 10 cents instead of $1) it'd be in my personal "definitely worth the trouble of doing" category.

RE: the scheme:  an OP_RINGSIGVERIFY is probably the right way to do this:
  https://en.wikipedia.org/wiki/Ring_signature

The funding transactions would be:  <public key> OP_RINGSIGVERIFY
... which might could be redeemed with <ring signature> for one input and then... uhh... maybe just <index_to_input_with_signature> for the other inputs that are part of the same ring signature group (OP_0 if the first input has the signature that is good for all the other public keys, which would be the common case).

--
--
Gavin Andresen