From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YzRpB-0004qf-VP for bitcoin-development@lists.sourceforge.net; Mon, 01 Jun 2015 15:40:25 +0000 X-ACL-Warn: Received: from mout.perfora.net ([74.208.4.196]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1YzRp9-0003vL-Ip for bitcoin-development@lists.sourceforge.net; Mon, 01 Jun 2015 15:40:25 +0000 Received: from mail-qc0-f181.google.com ([209.85.216.181]) by mrelay.perfora.net (mreueus002) with ESMTPSA (Nemesis) id 0LvBum-1Z8pgx3KmA-010LMf for ; Mon, 01 Jun 2015 17:40:17 +0200 Received: by qcej9 with SMTP id j9so6034163qce.1 for ; Mon, 01 Jun 2015 08:40:17 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.55.55.74 with SMTP id e71mr39417189qka.65.1433173217284; Mon, 01 Jun 2015 08:40:17 -0700 (PDT) Received: by 10.96.112.164 with HTTP; Mon, 1 Jun 2015 08:40:17 -0700 (PDT) Date: Mon, 1 Jun 2015 16:40:17 +0100 Message-ID: From: Adam Back To: Gavin Andresen Content-Type: text/plain; charset=UTF-8 X-Provags-ID: V03:K0:nye7SYFeESitGeJSXQCCrnCzxPxuX8tJrEpOOzWv3SfuMwK/lmv /7UVrs2v/OiivJ7n83UZqajLBdShT+TwjFEHra9mlDrhN4cwHe/FVAHyOUcQLFeUC4H5dKu 5I7BnUZT7fdxvPQcOJ1Wdbfc9R+u/1SUSo5cX4y6DUUonspHFyDvAhZYi7YOfnMGQFTQvfV bJehGG2diy71d5w0T3OsA== X-UI-Out-Filterresults: notjunk:1; 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.196 listed in list.dnswl.org] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record X-Headers-End: 1YzRp9-0003vL-Ip Cc: Bitcoin Dev Subject: [Bitcoin-development] soft-fork block size increase (extension blocks) 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: Mon, 01 Jun 2015 15:40:26 -0000 Hi Gavin Sorry for slow response & broken threading - mailbox filled up & only saw your response on archive. I do earnestly think opt-in block-size increases are politically cleaner (gives different people different sized blocks by their own volition without forcing a compromise) and less risky than hard forks. Particularly if a hard-fork were really provoked without clear and wide consensus - dragons lay there. > Then ask the various wallet developer how long it would take them to update > their software to support something like this, I don't think thats any particular concern, extension block payments are forwards and backwards compatible. Businesses who are keen to have more transactions, would make it their problem to implement in their wallet, or ask the wallet vendor/maintainer they're working with to do it. Nothing breaks if they dont use it. The people that have the need for it will work on it. Market at work. If it turns out they dont really have a need for it, just projected huge numbers for their business plan that say dont materialise, well no foul. > and do some UI mockups of what the experience would look like for users. I am not a UX guy, but for example it might be appropriate for tipping services or other micropayments to use an extension block. Or small retail payments. They can choose what address they use. Merchants, integrators etc can do likewise. It gives plenty enough scope that people can work with useful trade-offs while others work on lightning. > If there are two engineering solutions to a problem, one really simple, and > one complex, why would you pick the complex one? Because the more complex one is safer, more flexible, more future proof and better for decentralisation (and so as a bonus and might actually get done without more months of argument as its less contentious because it gives users choice to opt-in). Bitcoin itself is complex, a central ledger is simpler but as we know uninteresting which is to say this is a security tradeoff. Obviously I do appreciate KISS as a design principle, and utility of incremental improvements, but this is a security trade-off we're discussing here. I am proposing a way to not weaken security, while getting what you think is important - access to more TPS with a higher centralisation tradeoff (for those who opt-in to it, rather than for everyone whether that tradeoff is strongly against their interests or not). The decentralisation metrics are getting worse, not better, see Greg Maxwell's comments http://www.reddit.com/r/Bitcoin/comments/37vg8y/is_the_blockstream_company_the_reason_why_4_core/crqg381 This would not by those metrics be a good moment in history to make the situation worse. > Especially if the complex solution has all of the problems of the simple > one (20MB extension blocks are just as "dangerous" as 20MB main blocks, > yes? If not, why not?) Not at all, thats the point. Bitcoin has a one-size fits all blocksize. People can pool mine the 8MB extension block, while solo or GBT mining the 1MB block. Thats more centralising than staying at 1MB (because to get the fees from the extension block some people without that kind of bandwidth are pool mining 8/9th of the lower security/decentralisation transactions. But its less centralising than a fixed blocksize of 9MB (1+8 for apples/apples) because realistically if those transactions are not spam, they would've happened offchain, and offchain until we get lightning like systems up, means central systems which are worse than the slight centralisation of 8MB blocks being single servers and prone to custody & security failure. I think you made that point yourself in a recent post also. Sound good? ;) Seriously I think its the least bad idea I've heard on this topic. As an aside, a risk with using companies as a sounding board, is that you can get a misleading sense of consensus. Did they understand the tradeoff between security (decentralisation) and blocksize. Did they care? Do they represent users interests? Would they have "voted" instead for extension blocks if it was presented in similar terms? (I have to imagine they might have preferred extension blocks given the better story if you gloss over complexity and tradeoffs). Adam