Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id BE7CF9D for ; Tue, 24 Nov 2015 20:32:40 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lf0-f45.google.com (mail-lf0-f45.google.com [209.85.215.45]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B1FCB87 for ; Tue, 24 Nov 2015 20:32:39 +0000 (UTC) Received: by lfs39 with SMTP id 39so34365312lfs.3 for ; Tue, 24 Nov 2015 12:32:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5Yf4BaiZl5BXxoKK9GB6beJoecjxMo3dSdDiEBo3RIc=; b=x+yo97u4L+UUh3WJKROoY05F7BraTjb68xYMTPRjF1VzsjhgsOhmuRjBVZ346HKJ+b CNY2Ki/RaavLcDPXbyoHWzLCZ+b3qf7TTZRLfzfzh8lw0IHyoRRc7UwDFVtV8hzxPzKV YQh15LAkXF6PECgz+gFTFULVym1eFXQGa52cJOSQV9HQY5eE8BZL9OUKtuOeiQfyG7Ql P5cpftxLLjyGd5prQRmQ7ArXnOsS0f6Os1j73QKoeWaqIM+LMx7UNGVLz4yaJCT4fAeO eUKAmIErwK5eMNLHlGFvSyEC9/6yI7/BEfZYhGqdG6LyD2eUdCBwL4tK2IQ38Zaw6R+8 y+rA== MIME-Version: 1.0 X-Received: by 10.112.172.138 with SMTP id bc10mr13581806lbc.74.1448397157398; Tue, 24 Nov 2015 12:32:37 -0800 (PST) Received: by 10.25.22.95 with HTTP; Tue, 24 Nov 2015 12:32:37 -0800 (PST) In-Reply-To: References: Date: Tue, 24 Nov 2015 15:32:37 -0500 Message-ID: From: Gavin Andresen To: Chris Priest Content-Type: multipart/alternative; boundary=001a11c267140f7f0c05254f3e3c X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] OP_CHECKWILDCARDSIGVERIFY or "Wildcard Inputs" or "Coalescing Transactions" X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 20:32:40 -0000 --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: OP_RINGSIGVERIFY ... which might could be redeemed with for one input and then... uhh... maybe just 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
On T= ue, Nov 24, 2015 at 12:34 PM, Chris Priest via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
The techni= cal 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:
=C2=A032-byte hash (transaction being spent)<= /div>
=C2=A04-byte output (output being spent)=C2=A04-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 th= e BIP70 payment protocol), and which is at least two serialized bytes.

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'd pay 37 cents.

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

= RE: the scheme: =C2=A0an OP_RINGSIGVERIFY is probably the right way to do t= his:

The funding transactions would be: =C2=A0<public key> OP_RING= SIGVERIFY
... which might could be redeemed with <ring signatu= re> 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--