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 4CF4771 for ; Sat, 6 Aug 2016 18:53:17 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from zinan.dashjr.org (unknown [192.3.11.21]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 95A0F137 for ; Sat, 6 Aug 2016 18:53:16 +0000 (UTC) Received: from ishibashi.localnet (adsl-98-70-231-167.gnv.bellsouth.net [98.70.231.167]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id 4745338A17C7; Sat, 6 Aug 2016 18:52:58 +0000 (UTC) X-Hashcash: 1:25:160806:cp368202@ohiou.edu::k+/oa4=kd80J2V1v:aA3KE X-Hashcash: 1:25:160806:bitcoin-dev@lists.linuxfoundation.org::6DyRP00W6RC206hT:apSq5 From: Luke Dashjr To: Chris Priest , Bitcoin Protocol Discussion Date: Sat, 6 Aug 2016 18:52:55 +0000 User-Agent: KMail/1.13.7 (Linux/4.1.18-gentoo; KDE/4.14.20; x86_64; ; ) References: In-Reply-To: X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F X-PGP-Key-ID: BD02942421F4889F X-PGP-Keyserver: hkp://pgp.mit.edu MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201608061852.56738.luke@dashjr.org> X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,RDNS_DYNAMIC autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [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 18:53:17 -0000 This is exactly what segwit does... On Saturday, August 06, 2016 2:15:22 PM Chris Priest via bitcoin-dev wrote: > 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? > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev