From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z4ewU-0002SH-Li for bitcoin-development@lists.sourceforge.net; Tue, 16 Jun 2015 00:41:30 +0000 X-ACL-Warn: Received: from mail-ie0-f177.google.com ([209.85.223.177]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z4ewQ-0000DT-Bc for bitcoin-development@lists.sourceforge.net; Tue, 16 Jun 2015 00:41:30 +0000 Received: by iesa3 with SMTP id a3so3146541ies.2 for ; Mon, 15 Jun 2015 17:41:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=IJvnpisBujod4PLvRY77AvqprgPMEKDIHpyB9gcHFFI=; b=SzvqLT/hTebN2nfohfJeGzReb6tVmMXRk5P2z8m7wXiz8YKfBb7xmsBjcwcDmhZTNm 38ZXbdRBbGimrQJ4HbFyRpuxnak7lJIu7FQtLl9z/8HkdQT74O//AMlXOzC5KXyp6J1d LH6mcxLbVMZHYMgmuuN9tAB82X/fWy/M7R158Ml29Nq7/TH6WbU1mbbH69Q8uRYESQjC +j7DiTQ91mO156v/kemgZe84HXjq1ykZePYkPRZvprokVNww9bHzer/5Fq8e3YMjnITC guJho5xgXdFQfTU/TnfaHrdfgHT7d+SOt/lf4qCjJk031/8Kk9ZvAG4uf0hVGife3itR 6C1w== X-Gm-Message-State: ALoCoQmUk8uuCmtLqmdD+5JUmyHkC+QQyR6IN16usGxHtlmFILpnfiWpedrNyR+PG/MRj4tWhyMq X-Received: by 10.50.62.148 with SMTP id y20mr3926025igr.17.1434415280907; Mon, 15 Jun 2015 17:41:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.149.20 with HTTP; Mon, 15 Jun 2015 17:41:00 -0700 (PDT) X-Originating-IP: [172.56.17.8] In-Reply-To: References: <9834E283-727C-47F7-A3D0-667951727E5F@gmail.com> From: Mark Friedenbach Date: Mon, 15 Jun 2015 17:41:00 -0700 Message-ID: To: Aaron Voisine Content-Type: multipart/alternative; boundary=047d7bdcab34479266051897d509 X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1Z4ewQ-0000DT-Bc Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork 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: Tue, 16 Jun 2015 00:41:30 -0000 --047d7bdcab34479266051897d509 Content-Type: text/plain; charset=UTF-8 On Mon, Jun 15, 2015 at 5:08 PM, Aaron Voisine wrote: > Wasn't the XT hard fork proposed as a last resort, should the bitcoin-core > maintainers simply refuse to lift the 1Mb limit? No one wants to go that > route. An alternate hard-fork proposal like BIP100 that gets consensus, or > a modified version of gavin's that ups the limit to 8Mb instead of 20Mb, or > hell even some major changes to the non-consunsus code to make it > adequately handle the situation when blocks fill up, and allow wallet > software to continue working with a send-and-forget use pattern, any of > these would be enough to avoid the need for an XT only hard-fork. > > So far BIP100 is the only one that seems to actually be getting any sort > of momentum toward consensus, and it was proposed... 2 days ago? When the > XT fork was proposed as a last resort, it was when the opponents were (to > my understanding) suggesting we just let blocks fill up, and hopefully > things would just work out on their own. > We are not reaching consensus about any proposal, Garzik's or otherwise. --047d7bdcab34479266051897d509 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jun 15, 2015 at 5:08 PM, Aaron Voisine <voisine= @gmail.com> wrote:
Wasn't the XT hard= fork proposed as a last resort, should the bitcoin-core maintainers simply= refuse to lift the 1Mb limit? No one wants to go that route. An alternate = hard-fork proposal like BIP100 that gets consensus, or a modified version o= f gavin's that ups the limit to 8Mb instead of 20Mb, or hell even some = major changes to the non-consunsus code to make it adequately handle the si= tuation when blocks fill up, and allow wallet software to continue working = with a send-and-forget use pattern, any of these would be enough to avoid t= he need for an XT only hard-fork.

So far BIP100 is the o= nly one that seems to actually be getting any sort of momentum toward conse= nsus, and it was proposed... 2 days ago? When the XT fork was proposed as a= last resort, it was when the opponents were (to my understanding) suggesti= ng we just let blocks fill up, and hopefully things would just work out on = their own.

We are not reaching = consensus about any proposal, Garzik's or otherwise.
--047d7bdcab34479266051897d509--