Date: Mon, 28 Sep 2015 11:05:43 -0400
From: Peter Todd <pete@petertodd.org>
To: Mike Hearn <hearn@vinumeris.com>
Message-ID: <20150928150543.GB28939@savin.petertodd.org>
References: <20150927185031.GA20599@savin.petertodd.org>
	<CA+w+GKRCVr-9TVk66utp7xLRgTxNpxYoj3XQE-6y_N8JS6eO6Q@mail.gmail.com>
	<20150928132127.GA4829@savin.petertodd.org>
	<CA+w+GKTCZDNVJ-XEmsCAWGXUV3xOzVYmqMQYm0x+ihyYWQN0Gg@mail.gmail.com>
	<20150928142953.GC21815@savin.petertodd.org>
	<CA+w+GKTUz2eVJOpixSebWiQ59ovoELNhsZWSsbLHXWqk2eCn0A@mail.gmail.com>
	<20150928144318.GA28939@savin.petertodd.org>
	<CA+w+GKSuO2v+92hJUckcYdHcjkPVNg4opDL98yygGp-gqB9Jtg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="wzJLGUyc3ArbnUjN"
Content-Disposition: inline
In-Reply-To: <CA+w+GKSuO2v+92hJUckcYdHcjkPVNg4opDL98yygGp-gqB9Jtg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
Precedence: list


--wzJLGUyc3ArbnUjN
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Sep 28, 2015 at 04:51:22PM +0200, Mike Hearn wrote:
> >
> > Ok, so again, if that's your security criteria, what's the issue
> > with soft-forks?
>=20
>=20
> Please read my article as it's all explained there.

I have read your article. In fact we reviewed it at a NY BitDevs meetup
that I attended.

> But to reiterate: the risk is that miners will build invalid blocks on top
> of the best work chain, instead of an ignored lower work side chain. This
> opens users to payment fraud. With a hard fork, all the blocks by miners
> that aren't checking all the rules anymore get neatly collected together =
on
> a side chain after the split, and wallets all know how to ignore that cha=
in.

Can you explain exactly how you think wallets will "know" how to ignore
the invalid chain?

With an advertised soft-fork, e.g. the IsSuperMajority() mechanism,
ignoring the invalid chain is easy: use nVersion to detect invalid
blocks when you know what soft-forks are coming up, and if presented
with an unknown - but advertised - soft-fork at minimum loudly warn the
user. In the case of a hard-fork identical logic can be used. (BIP101
being an example of a hard-fork triggered in a way that can be detected
by SPV clients, both explicitly (BIP101 specific) and implicitly
(general unknown block nVersion warnings))

> Yes, you made OP_NOPs be non-standard. So out of the box, miners won't
> create invalid blocks, as long as they're running Core past that version.
> But this makes the IsStandard function very much like a part of the
> consensus rules, as bypassing it can result in invalid blocks being
> created.

How so? Miners can always choose to create invalid blocks, thus
attacking SPV wallets; my statement with regard to pull-req #5000 comes
=66rom a risk-based approach, knowing that every invalid block is
expensive and the new concern created by a soft-fork is whether or not
miners will create them accidentally; miners can always create invalid
blocks delibrately.

> Miners have always understood that they can modify this function,
> or even bypass it entirely, without affecting the validity of their block=
s.
> And some miners do exactly that.

That's incorrect: Miners bypassing IsStandard() risk creating invalid
blocks in the event of a soft-fork. Equally, we design soft-forks to
take advantage of this.

> So I'll repeat the question that I posed before - given that there are
> clear, explicit downsides, what is the purpose of doing things this way?
> Where is the gain for ordinary Bitcoin users?

We seem to be in strong disagreement about which option has "clear,
explicit downsides"

--=20
'peter'[:-1]@petertodd.org
0000000000000000006f2abe95e361b73289e4a79ba3124801896f6b7dc8d977

--wzJLGUyc3ArbnUjN
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQGrBAEBCACVBQJWCVdDXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwZDZjYTE2YjNiNTRjMWQ5ODI0NGZkYmZmYzg1ZjJhZjAy
MDY4MjlkMDc3OGEyNWEvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkftiIggAnkcSgmIn5hsltGI0lmPeiylp
ZhMjUsXl40ZkOYq5/KIpVw9JBO6zUvG+C7dsd6TbOdcCfVyMaXhbBa0J41XiipBM
PU4FdlpNhMJuqHcu9i4wNdljnN0zBpw0QO1n1vSZuY6w5dGze/z5OvSxbAEW1Klx
3U7U+HV5cbcpZRPp9QEgswP5Ocstryxatw9pqz7NrOZNI8Af4qSm7IactigO4qhw
pq3c4irSk9zAsDDZ7sMZvlyIeyEUcy3EAdYCqyU6cHr27TcoXG4Sy74CPNWGw5V9
xpCH5ZiO6AswdD1f/SCHvxAS3FTKTYDY8d3qZh3nnjJ9jWN0hIg6rDM6xMdo2g==
=6i5f
-----END PGP SIGNATURE-----

--wzJLGUyc3ArbnUjN--