MIME-Version: 1.0
In-Reply-To: <CAAcC9yuM+dG+mJn_0vPqZuig5cHqeF-xgszw-zzD3D9UKRsyrQ@mail.gmail.com>
References: <CAAcC9yuM+dG+mJn_0vPqZuig5cHqeF-xgszw-zzD3D9UKRsyrQ@mail.gmail.com>
Date: Tue, 24 Nov 2015 15:32:37 -0500
Message-ID: <CABsx9T0A8EczcsE8f3D4WGk-0xsPadupBVgH5_kTs=GEhOq_9g@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Chris Priest <cp368202@ohiou.edu>
Content-Type: multipart/alternative; boundary=001a11c267140f7f0c05254f3e3c
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] OP_CHECKWILDCARDSIGVERIFY or "Wildcard Inputs" or
 "Coalescing Transactions"
Precedence: list

--001a11c267140f7f0c05254f3e3c
Content-Type: text/plain; charset=UTF-8

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

--001a11c267140f7f0c05254f3e3c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Nov 24, 2015 at 12:34 PM, Chris Priest via bitcoin-dev <span dir=3D"ltr=
">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_b=
lank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-w=
idth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding=
-left:1ex"><div id=3D":846" class=3D"" style=3D"overflow:hidden">The techni=
cal reason for this is that you have to explicitly list each<br>
UTXO individually when making bitcoin transactions. There is no way to<br>
say &quot;all the utxos&quot;. This post describes a way to achieve this. I=
&#39;m<br>
not yet a bitcoin master, so there are parts of this proposal that I<br>
have not yet figured out entirely, but I&#39;m sure other people who know<b=
r>
more could help out.<br></div></blockquote></div><br>So every input has:</d=
iv><div class=3D"gmail_extra">=C2=A032-byte hash (transaction being spent)<=
/div><div class=3D"gmail_extra">=C2=A04-byte output (output being spent)<br=
>=C2=A04-byte sequence number</div><div class=3D"gmail_extra">... plus the =
scriptSig. Which is as small as about 73 bytes if you&#39;re spending a raw=
 OP_CHECKSIG (which you can&#39;t do as a bitcoin address, but could via th=
e BIP70 payment protocol), and which is at least two serialized bytes.<br c=
lear=3D"all"><div><br></div><div>Best case for any scheme to coalesce scrip=
tSigs 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 transactio=
n would be about one-third the size, so instead of paying (say) $1 in trans=
action fees you&#39;d pay 37 cents.</div><div><br></div><div>That&#39;s in =
the gray are of the &quot;worth doing&quot; threshold-- if it was a 10x imp=
rovement (pay 10 cents instead of $1) it&#39;d be in my personal &quot;defi=
nitely worth the trouble of doing&quot; category.</div><div><br></div><div>=
RE: the scheme: =C2=A0an OP_RINGSIGVERIFY is probably the right way to do t=
his:</div><div>=C2=A0=C2=A0<a href=3D"https://en.wikipedia.org/wiki/Ring_si=
gnature">https://en.wikipedia.org/wiki/Ring_signature</a></div><div><br></d=
iv><div>The funding transactions would be: =C2=A0&lt;public key&gt; OP_RING=
SIGVERIFY</div><div>... which might could be redeemed with &lt;ring signatu=
re&gt; for one input and then... uhh... maybe just &lt;index_to_input_with_=
signature&gt; 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).</div><div><br></div>-- =
<br><div class=3D"gmail_signature">--<br>Gavin Andresen<br></div>
</div></div>

--001a11c267140f7f0c05254f3e3c--