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 EB9CCB0C for ; Mon, 7 Dec 2015 23:39:13 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com [209.85.213.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6F10E16C for ; Mon, 7 Dec 2015 23:39:13 +0000 (UTC) Received: by igl9 with SMTP id 9so85325112igl.0 for ; Mon, 07 Dec 2015 15:39:13 -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=ZqQEtKl/G/eS0+5Bq8GQK20M5tdHVW97NRttvVnBEpA=; b=Rq3C9qrYGWmtpVhiqKjr0y40/ktvzygW3hO1w1iSGaO501C87U1WRu4pARf/0YpDlX G3PjZV5q3bMZPubq8NRLn5wDi0nEjoHw4yk7gYDX7TN5pccRYlrAxaTpa3BH7DQ4m72H ZgYR+lhI5uWbEjHwe0NQ92RFUqArpZCpPRDx1lcdchQe5kX5w/RA/Zhz+id3MJnIm4uv nk/bfYTr9xvEg8l91YamJnKGa+UXR87gHxnsxlemm5ojvUYtzkQ28bNaOpqOGztHiTnG YbA7GnXUouU+jC57zJUGWBvEZ0xeGlvEh8KgKLpsV/FSfOltVQapA6ObpoCyc7owZNfi CcVw== MIME-Version: 1.0 X-Received: by 10.50.3.71 with SMTP id a7mr992685iga.80.1449531552888; Mon, 07 Dec 2015 15:39:12 -0800 (PST) Sender: nbvfour@gmail.com Received: by 10.36.20.130 with HTTP; Mon, 7 Dec 2015 15:39:12 -0800 (PST) Date: Mon, 7 Dec 2015 15:39:12 -0800 X-Google-Sender-Auth: yfifVLf3NJeBLxODKT0sdWCER4Q Message-ID: From: Chris Priest To: Bitcoin Dev 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] Coalescing Transactions BIP Draft 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: Mon, 07 Dec 2015 23:39:14 -0000 I made a post a few days ago where I laid out a scheme for implementing "coalescing transactions" using a new opcode. I have since come to the realization that an opcode is not the best way to do this. A much better approach I think is a new "transaction type" field that is split off from the version field. Other uses can come out of this type field, wildcard inputs is just the first one. There are two unresolved issues. First, there might need to be a limit on how many inputs are included in the "coalesce". Lets say you have an address that has 100,000,000 inputs. If you were to coalesce them all into one single input, that means that every node has to count of these 100,000,000 inputs, which could take a long time. But then again, the total number of inputs a wildcard can cover is limited to the actual number of UTXOs in the pool, which is very much a finite/constrained number. One solution is to limit all wildcard inputs to, say, 10,000 items. If you have more inputs that you want coalesced, you have to do it in 10,000 chunks, starting from the beginning. I want wildcard inputs to look as much like normal inputs as much as possible to facilitate implementation, so embedding a "max search" inside the transaction I don't think is the best idea. I think if there is going to be a limit, it should be implied. The other issue is with limiting wildcard inputs to only inputs that are confirmed into a fixed number of blocks. Sort of like how coinbase has to be a certain age before it can be spent, maybe wildcard inputs should only work on inputs older than a certain block age. Someone brought up in the last thread that re-orgs can cause problems. I don't quite see how that could happen, as re-orgs don't really affect address balances, only block header values, which coalescing transactions have nothing to do with. Here is the draft: https://github.com/priestc/bips/blob/master/bip-coalesc-wildcard.mediawiki