Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 4814067 for ; Wed, 5 Aug 2015 09:57:57 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C17317C for ; Wed, 5 Aug 2015 09:57:56 +0000 (UTC) Received: from mail-qg0-f48.google.com ([209.85.192.48]) by mrelay.perfora.net (mreueus002) with ESMTPSA (Nemesis) id 0Lm5DD-1YnJis3jrF-00ZheT for ; Wed, 05 Aug 2015 11:57:56 +0200 Received: by qged69 with SMTP id d69so25710467qge.0 for ; Wed, 05 Aug 2015 02:57:54 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.141.28.11 with SMTP id f11mr16290113qhe.78.1438768674891; Wed, 05 Aug 2015 02:57:54 -0700 (PDT) Received: by 10.96.226.68 with HTTP; Wed, 5 Aug 2015 02:57:54 -0700 (PDT) In-Reply-To: References: <1438640036.2828.0.camel@auspira.com> Date: Wed, 5 Aug 2015 11:57:54 +0200 Message-ID: From: Adam Back To: Hector Chu Content-Type: text/plain; charset=UTF-8 X-Provags-ID: V03:K0:tO4FfUinjaBi1G7yHPsgNI2InOQv+0knko6Xk5WPmFS0j5TOwdZ Q9P87K0X2nIB+SSt9aWInE5fD52hVVPpxwjGlgvqsC3D2Dcl7MtEtOSQ5ngAMwHtb/JfWWT tulnKlcHu0QsGOkHtXicicRLTguQ4oy9pfEWMrzGgugWXIHOmeW2n/w9UHTevU+KaK9e9IJ Np5Ssts5FBeTz8REQtmsg== X-UI-Out-Filterresults: notjunk:1;V01:K0:vQiworOb6HA=:xlf7YvOG87GWE8aWmFq1+z 619k49x/sKSNf1//Gdw+boHMyv1/MPrmCUIgytgPaoJYUooYRISq4w/X3/OHa2OL0vccMO1oc N0P6CWNhGE65+I35Eh3xsHPp4OJ+3zqeP9k5JCOBTHyAyLpQ+yXy970EKXC8LtfClj06/royG uhQfa+e9IMNyGsCDtjWvikFhwPETOm2EQa7Gbb+mLj+7vQEW5qHZdn5xiU3Hkp39VihgjikN3 OLvfeBnCBRppSNzFxU6zW3mAQcnGgchXmRlmwtbTIV5rO6iNoYAmZkyOApzDJQbD4XXXDQ+Rn M0SNG3EP/it7Iunz5iVyw0Yq36Ctfd1Tr6vnr3Vti2qWoq8j5HY8y8XSMAdlXPVY9L9GBHhqP AhkMBsP+70rC9QUF72Av4tu+Oydj7Jn5x5aTymp8DW6ZVKES4U7L57V+82wL/6Ov4N11RAsjp JeaUlTzeTQ9biDE7UJ/Hcz2T6JBIxD2/LrE5cuELhtyi/SYebemU+5HNl/8Rw3K+MitmLHdkr +3V/Q8a79jdMe1GLv1c4W9Z9lfRMigrlBh2evA2MTsb6XUSSiH8XaYOIXrDUoIhVpoSS4pakw 5c5GNGVdeVGEVSahpcpHbprAw5C6TDrOIj9VPMdIZJT0WydCQkgrayBE3nwnbUQ51w9pP2D8z zdvowZrD09ZNduTB+qlrd4CwaCriq6f09HgEyDjTvSRhlzA== X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests 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: Wed, 05 Aug 2015 09:57:57 -0000 On 5 August 2015 at 11:18, Hector Chu via bitcoin-dev wrote: > Miners would be uniquely placed to know how best to vary the block size to maximize their > profit resulting from these two prices. [...] > In that respect a dynamic block size voted on by miners periodically would > go some way to rectify this inefficiency. This kind of thing has been discussed here, even recently. It is not without problems. You may find the flexcap idea summarised in outline by Greg Maxwell and Mark Friedenbach a month or so back interesting in showing that one can achieve such effects without handing over a free vote to miners and hence avoid many (though probably not all) of the side-effects inherent in giving miners control. About side-effects, I think we can make argument that there are limits because other than in an extremis sense, miners are not necessarily in alignment with security, nor maximising user utility and value delivered. For example switching cost economics are common in networks (cell phone service pricing), maybe Bitcoin would have a really high switching cost if miners would cartelise. Also miners are in a complex game competing with each other, and this degree of control risks selfish mining issues or other cartel attacks or bandwidth/verification/latency related attacks being made worse. eg see the recent paper by Aviv Zohar. Generally speaking economically dependent full nodes are holding miners honest by design. Changing that dynamic by shifting influence can have security and control impacting side-effects, and needs to be thought about carefully. About security to try to make those comparisons a bit more formal I posted this taxonomy of types of security that proposals could be compared against, in order of security: 1. consensus rule (your block is invalid if you attack) 2. economic incentive alignment (you tend to lose money if you attack) 3. overt (attack possible but detectable, hence probably less likely to happen for reputation or market signal reasons even if possible anonymously) 4. meta incentive (assume people would not attack if they have an investment or interest in seeing Bitcoin continue to succeed) Adam