Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.175 as permitted sender)
	client-ip=74.125.82.175; envelope-from=andyparkins@gmail.com;
	helo=mail-we0-f175.google.com; 
From: Andy Parkins <andyparkins@gmail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
Date: Wed, 1 Feb 2012 09:46:31 +0000
User-Agent: KMail/1.13.6 (Linux/3.0.0-1-686-pae; KDE/4.6.3; i686; ; )
References: <201201311651.02726.andyparkins@gmail.com>
	<CAAS2fgTvvDT+acJQfwAGpVNeA2PAQ7wip9xXc-__V2oz-=Kk6Q@mail.gmail.com>
In-Reply-To: <CAAS2fgTvvDT+acJQfwAGpVNeA2PAQ7wip9xXc-__V2oz-=Kk6Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1372095.UjJ9JDOvRM";
	protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <201202010946.37807.andyparkins@gmail.com>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] BIP16/17 replacement
Precedence: list

--nextPart1372095.UjJ9JDOvRM
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On 2012 January 31 Tuesday, Gregory Maxwell wrote:

> I think you've been deceived by people who have some interest in
> promoting this as some sort of big controversy, or perhaps just
> confused by the general level of noise.

Well that's good that there is no real problem.

> It does not, in fact=E2=80=94 Yes, it requires a client update to make us=
e of
> the new functionality, but old nodes will happily continue to validate
> things.  It's hard to express how critical this is distinctly.
> Bitcoin is, predominantly, a zero-trust system. Nodes don't trust that
> things were done right, the validate them for themselves.
>=20
> A breaking change of the kind you suggest is not something that would
> be considered lightly, and this is certainly not justified for this.

To be brutally honest; I don't see how the BIP16/17 changes are any less=20
"breaking" than what I proposed (I'm not trying to push mine; forget it, th=
e=20
last thing bitcoin needs is another proposal if there is no real argument).=
 =20
I will agree the changes are smaller for BIP16, since the transactions are=
=20
left as they are.

If BIP16/BIP17 were being honest they would too increase the version number=
=20
of the transaction structure.  The new transaction type is not supported by=
=20
the old client... that's a break.  My argument would be that once you're=20
going to break the old clients anyway, go the whole hog and fix some other=
=20
stuff as well.

> If we ever were to scrap the system, I think we very much would do
> something like what you describe here... and as much has been
> documented:
>=20
> https://en.bitcoin.it/wiki/Hardfork_Wishlist
> (see "Elimination of output scripts")

I'm glad I wasn't talking rubbish then.
=20
> But, to be clear, this stuff is pretty much fantasy. I'm doubtful that
> it will ever happen, doubtful that we can get the kind of development

Me too.  Which is a shame; as it means we're locked into quite a fair numbe=
r=20
of earlier decisions that will now never be changed.

> resources required to pull off a true breaking change in a way that
> people would actually trust upgrading to=E2=80=94 at least not before a t=
ime
> that the system is simply too big to make that kind of change.

Again: I don't see how BIP16/17 aren't "breaking" as well; but perhaps I'm=
=20
just not familiar enough with the conventions.  As far as I understand; no=
=20
pre-BIP16 miner is going to allow BIP16 into the blockchain because it's no=
t=20
going to pass the IsStandard() test.

I'd repeat: the reasonable thing to do is to increase the version number of=
=20
the transaction structure to indicate that they are being processed=20
differently from old transactions.


Andy
=2D-=20
Dr Andy Parkins
andyparkins@gmail.com

--nextPart1372095.UjJ9JDOvRM
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk8pCfgACgkQwQJ9gE9xL22nIQCfUxsxUhzm6f+K9sPpZUoQioba
Cw8An2bpp2CzDnIFnC6tjjdEsi3KL7Dk
=743B
-----END PGP SIGNATURE-----

--nextPart1372095.UjJ9JDOvRM--