From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z4FNr-0000E3-0k for bitcoin-development@lists.sourceforge.net; Sun, 14 Jun 2015 21:24:03 +0000 X-ACL-Warn: Received: from mout.perfora.net ([74.208.4.197]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1Z4FNp-00078T-So for bitcoin-development@lists.sourceforge.net; Sun, 14 Jun 2015 21:24:03 +0000 Received: from mail-qg0-f44.google.com ([209.85.192.44]) by mrelay.perfora.net (mreueus001) with ESMTPSA (Nemesis) id 0M9qO6-1YtDoi0Day-00B8Kx for ; Sun, 14 Jun 2015 23:23:56 +0200 Received: by qgf75 with SMTP id 75so21825236qgf.1 for ; Sun, 14 Jun 2015 14:23:55 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.140.101.97 with SMTP id t88mr32198522qge.9.1434317035453; Sun, 14 Jun 2015 14:23:55 -0700 (PDT) Received: by 10.96.20.164 with HTTP; Sun, 14 Jun 2015 14:23:55 -0700 (PDT) Date: Sun, 14 Jun 2015 23:23:55 +0200 Message-ID: From: Adam Back To: Bitcoin Dev Content-Type: text/plain; charset=UTF-8 X-Provags-ID: V03:K0:obEbCT23uz6Jsb72clfJNH3seFZDadU1F6o0dTLBiqUSOUmiJAl ehVjtl/NCHyLK+tS29RjE+zUyM9MnNFhKfYke4lEUOom/mbxb5DDt+yxogstSklJTg/yNSD FzdaAFbo3dUaCo8B3J/MfZGtZ/RCmq3834bwoYSI5yOiPfPyfnK6Frj0Mfb2TXu7l9apTBC Vnh0nZTjmcHR/NeSV9jNQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:2f4Uy35bsKA=:jgPDJN7IRPrDSR08u28CAu euOlurrrYmQ7VYbhD7r/sBkIQzOYXuxC9o2XtNoxvh2ykGAoXorRsMuYSa1v0J7NO4HiVXqmG 5FWU1QI4FNwG0jQbU9+0ycwe7SQf6COu3YoDZkeP4gvS5mkiE24eC6ah1SJl3TnRzmYKatOSb fgWMh3ErtJZAWzHoip9h73X5LKgkPukYfW28CgaZcXSm9LtoeKFwX21u6YFlkgqzo+S4KckEe V5ygknruBoWjAkPvhYRBOYETUmXM4o6uqKepsZv8IHQnn5aB9xe3fjbw3ETXZU83RmF0c43NH DdF8Hv6bhPpkPpisMXZZCSeVPHU8YtDl4s97AcDkgO6JPmSUFXZxqR02qqbcVwyAH5jKwavQ9 z5VuMvYr5j8tHeYnpYlX18xRjlc67yBia0VH5FHd4FcULNvbLJJDlMS9rr3QF+AHHMkzAQXjA Nzgy3qJG5qzie7vD9aNJRpvl4luPXRlcCE/ZnpIsuKJNj78uLQ62fKVdZM1QlxwPtWzACA6nx ltAfWVhvltrE8pXI6uX5pLBlLbxGmj4ht/T7cgwDtZwLCtn/Kqys+3+FLQCx5eKxcRXzQziLK 2NJVuaOhTypGmHnAfFilwu0iQ8JFCW4urc4/RIJH9LnGERcMEEinqjraBgdEuOwXVJJIFBPrF lCyms4XQdHiwgbBE6e4QYMA7aF+tWWaescgOUNuJ3Qv3b9g== X-Spam-Score: -0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [74.208.4.197 listed in list.dnswl.org] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record X-Headers-End: 1Z4FNp-00078T-So Subject: [Bitcoin-development] comments on BIP 100 X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2015 21:24:03 -0000 Hi I made these comments elsewhere, but I think really we should be having these kind of conversations here rather than scattered around. These are about Jeff Garzik's outline draft BIP 100 I guess this is the latest draft: (One good thing about getting off SF would be finally JGarzik's emails actually not getting blocked!). http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf may have changed since the original [1] Over the original proposal: 1. there should be a hard cap, not indefinitely growing. 2. there should be a growth limiter (no more than X%/year) 3. I think the miners should not be given a vote that has no costs to cast, because their interests are not necessarily aligned with users or businesses. I think Greg Maxwell's difficulty adjust [2] is better here for that reason. It puts quadratic cost via higher difficulty for miners to vote to increase block-size, which miners can profitably do if there are transactions with fees available to justify it. There is also the growth limiter as part of Greg's proposal. [3] I think bitcoin will have to involve layering models that uplift security to higher layers, but preserve security assurances, and smart-contracts even, with protocols that improve the algorithmic complexity beyond O(n^2) in users, like lightning, and there are multiple other candidates with useful tradeoffs for various use-cases. One thing that is concerning is that few in industry seem inclined to take any development initiatives or even integrate a library. I suppose eventually that problem would self-correct as new startups would make a more scalable wallet and services that are layer2 aware and eat the lunch of the laggards. But it will be helpful if we expose companies to the back-pressure actually implied by an O(n^2) scaling protocol and don't just immediately increase the block-size to levels that are dangerous for decentralisation security, as an interventionist subsidy to save them having to do basic integration work. Otherwise I think whichever any kind of kick the can some 2-5 years down the road we consider, we risk the whole saga repeating in a few years, when no algorithmic progress has been made and even more protocol inertia has set in. Adam [1] original proposal comments on reddit https://www.reddit.com/r/Bitcoin/comments/39kzyt/draft_bip_100_soft_fork_block_size_increase/ [2] flexcap propoal by Greg Maxwell see post by Mark Freidenbach https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07599.html [3] growth limited proposal for flexcap by Greg Maxwell https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07620.html