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 0E409899 for ; Sat, 6 Aug 2016 14:15:25 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f172.google.com (mail-qk0-f172.google.com [209.85.220.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5AE64112 for ; Sat, 6 Aug 2016 14:15:24 +0000 (UTC) Received: by mail-qk0-f172.google.com with SMTP id t7so11154633qkh.0 for ; Sat, 06 Aug 2016 07:15:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=bfzvb0ioKkvjIqH2HGQEL3jjxjPkoEfg5VdtvIogPGg=; b=IHzDiU+oyeDnza5xyCIcdI5EZMONaXrK2P4zcbDoeU7/h5eo4dzRqjI62S9bK5F7lY lAkiBFGsLum0hBIr3VdYp89lERSVNuSy8u/8eac25OUptIdPF2HO/w3+fTgKVtGgDGjE Ae5cuOI0VmVstlzPQyj1t6qoNUw2tmj4XFubJl3BkRoi3Ju20l/5zIZsvESIpL/4nwQE woXYhcC3UAJRTtpZdSfeuO0fLv/wpR8DGDyza8dtcmGhTFU3W0mfygxY02OubiCRKph5 tuW80dZ3OsWyHvmDLa1tvRzZze8/uQ0Pj5dJtYvhcbCKiHlf802l6QrpRMDob78OuN3W oEcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=bfzvb0ioKkvjIqH2HGQEL3jjxjPkoEfg5VdtvIogPGg=; b=YxeWVkXmP2g4HiC2neXkg+1+KOx4iex7bzYJmWPBkPOAMd1WAab8Fb7IFDJAqsQaVg d1ELdbG0AQBcJdTv4mBltly+1ZHBSUh8L9Bi5zVM/CEiVA9t79e/Lz9Y9rBZqrwUGt/R IE0qonk5jjNp+WvzQu4K2Vy/QfrgZc46M0d/srMpjuqQ1YOCgJHgksl9Zgb/oMSQDnkd yyV46edy1NedGm2fzNfps6xwk/rX0VXUAWcmFItFhBzTQFBl4r1DH2m80PqogmQgJiJP aD7mfYz0UaVT30biSco68x3t739SlypbDWEBj75b89FArdQF8wpU4FoJdS66avmefuSt K+7w== X-Gm-Message-State: AEkooutTky2nBgNxuTcaScvmcZQWr6eLvQ0imhpo0cIeJzap3DrfUZ7cMPUf3JGWWXo2DffawNpXOYnszInIfQ== X-Received: by 10.55.116.70 with SMTP id p67mr17736441qkc.52.1470492923358; Sat, 06 Aug 2016 07:15:23 -0700 (PDT) MIME-Version: 1.0 Sender: nbvfour@gmail.com Received: by 10.237.55.199 with HTTP; Sat, 6 Aug 2016 07:15:22 -0700 (PDT) From: Chris Priest Date: Sat, 6 Aug 2016 07:15:22 -0700 X-Google-Sender-Auth: wLZsrYgqCCKi6WwGl-F1LaUgUyo Message-ID: 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] *Changing* the blocksize limit X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2016 14:15:25 -0000 Because the blocksize limit is denominated in bytes, miners choose transactions to add to a block based on fee/byte ratio. This mean that if you make a transaction with a lot of inputs, your transaction will be very big, an you'll have a to pay a lot in fees to get that transaction included in a block. For a long time I have been of the belief that it is a flaw in bitcoin that you have to pay more to move coins that are sent to you via small value UTXOs, compared to coins sent to you through a single high values UTXO. There are many legitimate uses of bitcoin where you get the money is very small increments (such as microtransactions). This is the basis for my "Wildcard inputs" proposal now known as BIP131. This BIP was rejected because it requires a database index, which people thought would make bitcoin not scale, which I think is complete malarkey, but it is what it is. It has recently occurred to me a way to achieve the same effect without needing the database index. If the blocksize limit was denominated in outputs, miners would choose transactions based on maximum fee per output. This would essentially make it free to include an input to a transaction. If the blocksize limit were removed and replaced with a "block output limit", it would have multiple positive effects. First off, like I said earlier, it would incentivize microtransactions. Secondly it would serve to decrease the UTXO set. As I described in the text of BIP131, as blocks fill up and fees rise, there is a "minimum profitability to include an input to a transaction" which increases. At the time I wrote BIP131, it was something like 2 cents: Any UTXO worth less than 2 cents was not economical to add to a transaction, and therefore likely to never be spent (unless blocks get bigger and fee's drop). This contributes to the "UTXO bloat problem" which a lot of people talk about being a big problem. If the blocksize limit is to be changed to a block output limit, the number the limit is set to should be roughly the amount of outputs that are found in 1MB blocks today. This way, the change should be considered non-controversial. I think its silly that some people think its a good thing to keep usage restricted, but again, it is what it is. Blocks can be bigger than 1MB, but the extra data in the block will not result in more people using bitcoin, but rather existing users spending inputs to decrease the UTXO set. It would also bring about data that can be used to determine how to scale bitcoin in the future. For instance, we have *no idea* how the network will handle blocks bigger than 1MB, simply because the network has never seen blocks bigger than 1MB. People have set up private networks for testing bigger blocks, but thats not quite the same as 1MB+ blocks on the actual live network. This change will allow us to see what actually happens when bigger blocks gets published. Why is this change a bad idea?