Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.216.46 as permitted sender)
	client-ip=209.85.216.46; envelope-from=gmaxwell@gmail.com;
	helo=mail-qa0-f46.google.com; 
MIME-Version: 1.0
In-Reply-To: <CABsx9T1_R2RE0S=ygY18OyJ0W+Bxyt5Q75bF4J36r0C8ae4-Fw@mail.gmail.com>
References: <20120616192651.GA13438@vps7135.xlshosting.net>
	<CABsx9T1_R2RE0S=ygY18OyJ0W+Bxyt5Q75bF4J36r0C8ae4-Fw@mail.gmail.com>
Date: Sat, 16 Jun 2012 19:39:00 -0400
Message-ID: <CAAS2fgT=eLweqpmRGonuvEYfiGi4nbaKh-uw01PKyMC3qyY71A@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: text/plain; charset=UTF-8
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] After compressed pubkeys: hybrid pubkeys
Precedence: list

On Sat, Jun 16, 2012 at 5:41 PM, Gavin Andresen <gavinandresen@gmail.com> wrote:
> RE: 0x06/0x07 'hybrid' public keys:
>
>> Any opinions? Forbidding it certainly makes alternative implementation
>> slightly easier in the future, but I'm not sure the hassle of a network
>> rule change is worth it.
>
> I say treat any transactions that use them as 'non-standard' -- don't
> relay/mine them by default, but accept blocks that happen to contain
> them.
>
> I agree that a rule change isn't worth it right now, but making them
> non-standard now is easy and should make a rule change in the future
> easier.

ACK.  Hopefully no one will mine these before we can merge denying
them into another rule change. But if they do, oh well.