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 1AFA826C for ; Tue, 24 Nov 2015 17:34:37 +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 8A98D169 for ; Tue, 24 Nov 2015 17:34:36 +0000 (UTC) Received: by ioef137 with SMTP id f137so2444640ioe.0 for ; Tue, 24 Nov 2015 09:34:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=f3s6qECwLJNhh7t4ruxB+Kt3NlO25LiSoVys0cE6xl4=; b=OR0OAlB/DjvRA+un2EA2nb0/rl1cbJ+uVyUiVhlw8KI9tg3XZZRJFIjefs83CliqgC eqEhGAD63iCXKAtBgZNWF1rEbN0yvVdhPn2lU0RGHH26Nv70mCDVBMMiS1UE6pXe2DkG buLFeYo5/7sMWaaJhM57SKMR2o03JMFyo2J5jlCSK+ZdxFxak+UBMiBlqrOvaR8fDX2c 54mU/m9GEQDNIPy7dtZREveGZbs7zDw1KhaBo5oJoF619lSKBKyM9J+Qelay8uqrR8zO y7CndtCj58h6sNoz+wbSUepq0+/2s5CEyhVTkjeF3wFRPOGLuJ4+AvA3oRd+kHapyXAA 2Q0g== MIME-Version: 1.0 X-Received: by 10.107.3.163 with SMTP id e35mr28790476ioi.157.1448386475918; Tue, 24 Nov 2015 09:34:35 -0800 (PST) Sender: nbvfour@gmail.com Received: by 10.36.20.130 with HTTP; Tue, 24 Nov 2015 09:34:35 -0800 (PST) Date: Tue, 24 Nov 2015 09:34:35 -0800 X-Google-Sender-Auth: m-OKJIWOPA_BAMFPrI41CN2j-ZQ Message-ID: From: Chris Priest To: bitcoin-dev@lists.linuxfoundation.org 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 Subject: [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 17:34:37 -0000 Here is the problem I'm trying to solve with this idea: Lets say you create an address, publish the address on your blog, and tell all your readers to donate $0.05 to that address if they like your blog. Lets assume you receive 10,000 donations this way. This all adds up to $500. The problem is that because of the way the bitcoin payment protocol works, a large chunk of that money will go to fees. If one person sent you a single donation of $500, you would be able to spend most of the $500, but since you got this coin by many smaller UTXO's, your wallet has to use a higher tx fee when spending this coin. 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. **OP_CHECKWILDCARDSIGVERIFY** First, I propose a new opcode. This opcode works exactly the same as OP_CHECKSIGVERIFY, except it only evaluates true if the signature is a "wildcard signature". What is a wildcard signature you ask? This is the part that I have not yet 100% figured out yet. It is basically a signature that was created in such a way that expresses the private key owners intent to make this input a *wildcard input* ** wildcard inputs ** A wildcard input is defined as a input to a transaction that has been signed with OP_CHECKWILDCARDSIGVERIFY. The difference between a wildcard input and a regular input is that the regular input respects the "value" or "amount" field, while the wildcard input ignores that value, and instead uses the value of *all inputs* with a matching locking script. ** coalescing transaction" A bitcoin transaction that