[bitcoin-dev] OP_CHECKWILDCARDSIGVERIFY or "Wildcard Inputs" or "Coalescing Transactions"
gavinandresen at gmail.com
Tue Nov 24 20:32:37 UTC 2015
On Tue, Nov 24, 2015 at 12:34 PM, Chris Priest via bitcoin-dev <
bitcoin-dev at 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
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
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:
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).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bitcoin-dev