Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YyURc-0002K0-Lg for bitcoin-development@lists.sourceforge.net; Sat, 30 May 2015 00:16:08 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.215.52 as permitted sender) client-ip=209.85.215.52; envelope-from=gavinandresen@gmail.com; helo=mail-la0-f52.google.com; Received: from mail-la0-f52.google.com ([209.85.215.52]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YyURb-0002KW-K8 for bitcoin-development@lists.sourceforge.net; Sat, 30 May 2015 00:16:08 +0000 Received: by lagv1 with SMTP id v1so66801598lag.3 for ; Fri, 29 May 2015 17:16:01 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.72.164 with SMTP id e4mr7179788lbv.113.1432944961174; Fri, 29 May 2015 17:16:01 -0700 (PDT) Received: by 10.25.90.75 with HTTP; Fri, 29 May 2015 17:16:01 -0700 (PDT) In-Reply-To: References: Date: Fri, 29 May 2015 20:16:01 -0400 Message-ID: From: Gavin Andresen To: Adam Back Content-Type: multipart/alternative; boundary=001a11c2b61664c4b10517417fd6 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (gavinandresen[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -0.0 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1YyURb-0002KW-K8 Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] soft-fork block size increase (extension blocks) Re: Proposed alternatives to the 20MB stepfunction 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: Sat, 30 May 2015 00:16:08 -0000 --001a11c2b61664c4b10517417fd6 Content-Type: text/plain; charset=UTF-8 RE: soft-forking an "extension block": So... go for it, code it up. Implement it in the Bitcoin Core wallet. Then ask the various wallet developer how long it would take them to update their software to support something like this, and do some UI mockups of what the experience would look like for users. If there are two engineering solutions to a problem, one really simple, and one complex, why would you pick the complex one? 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?) -- -- Gavin Andresen --001a11c2b61664c4b10517417fd6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
RE: soft-forking an "extension block":

<= /div>
So... go for it, code it up. Implement it in the Bitcoin Core wal= let.

Then ask the various wallet developer how lon= g it would take them to update their software to support something like thi= s, and do some UI mockups of what the experience would look like for users.=

If there are two engineering solutions to a probl= em, one really simple, and one complex, why would you pick the complex one?=

Especially if the complex solution has all of the= problems of the simple one (20MB extension blocks are just as "danger= ous" as 20MB main blocks, yes? If not, why not?)

<= div>
--
--
Gavin Andresen
--001a11c2b61664c4b10517417fd6--