From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7DAB986 for ; Tue, 24 Nov 2015 21:01:28 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f195.google.com (mail-io0-f195.google.com [209.85.223.195]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CAB57138 for ; Tue, 24 Nov 2015 21:01:27 +0000 (UTC) Received: by ioef137 with SMTP id f137so2929864ioe.0 for ; Tue, 24 Nov 2015 13:01:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=oOTbwIvIEO7jeIGYpGgM+LRovnRXvg4fW9VgSYALWYY=; b=uqwPimIWErjKXZN/CumU9hdKtYyHY3jt8mOmHEDpWBrqHDN9nqZb0PwHM4JuzU8w3+ CPjkqNLN/fXbRWy7f3TEdPne6v7PQ59OheWeKP6l3hVykb/xOKpGbcKM9+Kc++qvAZXn 7uOlXoEbfLcNQr/gdbSTyg93wVvqogcGSYiX0dJJ3SxKPRx5zN7gM9sLzVehp5gnHExS yGp0PO+wBDK8iVzS39fJVERbViD0T0X8b7Frkw6Lx22eUnXiyExg9nZ5KTFtW/knGY3w sZW6g27wHghAoIH97z9xobXcfm6o68U78ylzLhay8lhcdobZFgV7vCwSp8Rnnp2FrsqJ a25Q== MIME-Version: 1.0 X-Received: by 10.107.13.143 with SMTP id 137mr22199268ion.72.1448398886674; Tue, 24 Nov 2015 13:01:26 -0800 (PST) Sender: nbvfour@gmail.com Received: by 10.36.20.130 with HTTP; Tue, 24 Nov 2015 13:01:26 -0800 (PST) In-Reply-To: References: Date: Tue, 24 Nov 2015 13:01:26 -0800 X-Google-Sender-Auth: DCD4R7qnGCkFc-mU6-RPrffQ0rE Message-ID: From: Chris Priest To: Gavin Andresen Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, 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 21:01:28 -0000 A coalescing transaction in my scheme is the same size as a normal transaction. You only include one UTXO, the rest are implied based on the presence of the OP_CHECKWILDCARDSIGVERIFY opcode. The code that determines if a UTXO is spent or not will need to be modified to include a check to see if any matching coalescing transactions exist in any later block. Maybe there should be a "coalescing pool" containing all coalescing transactions that make such a check faster. The part I'm not too sure about is the "wildcard signature". I'm not too versed in cryptography to know how exactly to pull this off, but I think it should be simple. You'd just have to some way inject a flag into the signing process that can be verified later. I originally wanted the "wildcardness" of the transaction expressed by the transaction version number. Basically any input that exists within a "version 2 transaction" is viewed as a wildcard input. Then I realized whats to stop someone from modifying the transaction from version 1 to version 2 and stealing someones funds. The "wildcardness" must be expressed in the signature so you know that the private key holder intended all inputs to be included. Hence the need for a new opcode. btw, this scheme is definitely in the 10x or higher gain. You could potentially spend an unlimited number of UTXOs this way. On 11/24/15, Gavin Andresen wrote: > 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 >