Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1RsX1A-0000VC-AS for bitcoin-development@lists.sourceforge.net; Wed, 01 Feb 2012 10:02:20 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.53 as permitted sender) client-ip=74.125.82.53; envelope-from=pieter.wuille@gmail.com; helo=mail-ww0-f53.google.com; Received: from mail-ww0-f53.google.com ([74.125.82.53]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1RsX14-0000Kh-R0 for bitcoin-development@lists.sourceforge.net; Wed, 01 Feb 2012 10:02:20 +0000 Received: by wgbdr12 with SMTP id dr12so1018218wgb.10 for ; Wed, 01 Feb 2012 02:02:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.180.100.234 with SMTP id fb10mr40383795wib.8.1328090528617; Wed, 01 Feb 2012 02:02:08 -0800 (PST) Received: by 10.223.68.211 with HTTP; Wed, 1 Feb 2012 02:02:08 -0800 (PST) Received: by 10.223.68.211 with HTTP; Wed, 1 Feb 2012 02:02:08 -0800 (PST) In-Reply-To: <201202010948.13169.andyparkins@gmail.com> References: <201201311651.02726.andyparkins@gmail.com> <201201311158.50801.luke@dashjr.org> <201202010948.13169.andyparkins@gmail.com> Date: Wed, 1 Feb 2012 11:02:08 +0100 Message-ID: From: Pieter Wuille To: Andy Parkins Content-Type: multipart/alternative; boundary=f46d043748f33015fe04b7e42ccc X-Spam-Score: -1.1 (-) 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 (pieter.wuille[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.5 AWL AWL: From: address is in the auto white-list X-Headers-End: 1RsX14-0000Kh-R0 Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] BIP16/17 replacement 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: Wed, 01 Feb 2012 10:02:20 -0000 --f46d043748f33015fe04b7e42ccc Content-Type: text/plain; charset=ISO-8859-1 Op 1 feb. 2012 10:48 schreef "Andy Parkins" het volgende: > > On 2012 January 31 Tuesday, Luke-Jr wrote: > > > Both BIP 16 and 17 are backward compatible enough that people can continue > > to use the old clients with each other. An upgrade is only required to > > send to (or create/receive on) the new 3...-form addresses. That being > > Is that true? (I'm happy to be called wrong) > > It doesn't seem like it to me. The new transaction types will be rejected by > old clients won't they? They don't pass IsStandard(). IsStandard() is for accepting transactions into the memory pool. Non-standard transactions are verified just fine when they are in the block chain. BIP16/17 both create transactions that, when interpreted as old scripts, are valid. The only change to the protocol is that previously-valid transactions become invalid. As long as a supermajority of miners enforce the new rules, everyone can happily keep using their old bitcoin client. They won't create the new transaction type, and don't accept them as payment, but they will accept the new block chain. If we do a breaking change to the protocol - such as adding a new transaction type - ALL users must upgrade. Those who don't will see a fork of the chain from before the first new-style transaction. That is not the case now. -- Pieter --f46d043748f33015fe04b7e42ccc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


Op 1 feb. 2012 10:48 schreef "Andy Parkins" <andyparkins@gmail.com> het volgende:
>
> On 2012 January 31 Tuesday, Luke-Jr wrote:
>
> > Both BIP 16 and 17 are backward compatible enough that people can= continue
> > to use the old clients with each other. An upgrade is only requir= ed to
> > send to (or create/receive on) the new 3...-form addresses. That = being
>
> Is that true? =A0(I'm happy to be called wrong)
>
> It doesn't seem like it to me. =A0The new transaction types will b= e rejected by
> old clients won't they? =A0They don't pass IsStandard().

IsStandard() is for accepting transactions into the memory pool. Non-sta= ndard transactions are verified just fine when they are in the block chain.=

BIP16/17 both create transactions that, when interpreted as old scripts,= are valid. The only change to the protocol is that previously-valid transa= ctions become invalid. As long as a supermajority of miners enforce the new= rules, everyone can happily keep using their old bitcoin client. They won&= #39;t create the new transaction type, and don't accept them as payment= , but they will accept the new block chain.

If we do a breaking change to the protocol - such as adding a new transa= ction type - ALL users must upgrade. Those who don't will see a fork of= the chain from before the first new-style transaction. That is not the cas= e now.

--
Pieter

--f46d043748f33015fe04b7e42ccc--