Date: Mon, 28 Sep 2015 10:29:53 -0400
From: Peter Todd <pete@petertodd.org>
To: Mike Hearn <hearn@vinumeris.com>
Message-ID: <20150928142953.GC21815@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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="wxDdMuZNg1r63Hyj"
Content-Disposition: inline
In-Reply-To: <CA+w+GKTCZDNVJ-XEmsCAWGXUV3xOzVYmqMQYm0x+ihyYWQN0Gg@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


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

On Mon, Sep 28, 2015 at 03:41:56PM +0200, Mike Hearn wrote:
> >
> > 1) Do you agree that CLTV should be added to the Bitcoin protocol?
> >
> > Ignoring the question how exactly it is added, hard-fork or soft-fork.
> >
>=20
> The opcode definition seems OK.

Good!

> > 2) Will you add a IsSuperMajority() CLTV soft-fork to Bitcoin XT if it
> >    is added to Bitcoin Core?
> >
>=20
> Yes. It might be worth putting the version bit change behind a command li=
ne
> flag though: the BIP, as written, has problems (with deployment).

Could you elaborate on what exatly you mean by this.

> > 3) Will you add soft-fork detection to bitcoinj, to allow SPV clients to
>=20
>    detect advertised soft-forks and correctly handle them?
> >
>=20
> I'd really hate to do that. It'd be a Rube Goldberg machine:
>=20
>    https://krypt3ia.files.wordpress.com/2011/11/rube.jpg
>=20
> There's no really good way to do what you propose, and we already have a
> perfectly workable mechanism to tell SPV clients about chain forks: the
> block chain itself. This has the advantage of being already implemented,
> already deployed, and it works correctly.

SPV wallets can't detect hard-forks, so in both cases you will have
invalid blocks be accepted by SPV clients; there's no deployment
scenario for either hard or soft forks that guarantees all miners adopt
a fork.

What does prevent invalid blocks being accepted by SPV clients is
checking the block nVersion field and applying forking logic. Of course,
that only works for advertised forks, but again, that's equally true for
soft and hard forks.

> Attempting to strap a different mechanism on top to try and make soft for=
ks
> more like hard forks would be a large and pointless waste of people's time
> and effort, not just mine (bitcoinj is not the only widely used SPV
> implementation nowadays). You may as well go straight to the correct
> outcome instead of trying to simulate it with ever more complex mechanism=
s.

Again, in neither case do you get the "correct outcome" of SPV clients
accepting no invalid blocks without nVersion field checking.

However, in the hard-fork case, because the non-adopting miners reject
the fork, they build a chain which could be used to attack SPV clients
with false confirmations by sybil attacking those clients. In the
soft-fork case, the non-adopting miners keep accepting the longer chain
built by the adopting miners, preventing the creation of a chain that
could be used to attack SPV miners.


BTW, what's the other widely used SPV implementation you're thinking of?
I'll contact them directly and help them implement proper SPV fork
protections if they haven't already; if bitcoinj is unwilling to do this
at least we could have an alternative implementation that does.
(equally, if anyone wants to fork bitcoinj and correct this flaw I'd be
happy to help advise)

--=20
'peter'[:-1]@petertodd.org
00000000000000000ca626374f25dadbbb9245e60563a4d876f3c73070ad3849

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

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

iQGrBAEBCACVBQJWCU7eXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAxMGIwZjU1MDU2MmI3NDNjMmU0ZGM1YWYwMzg1ZWE1OGE2
ZWNlMzJkODc4M2EwOTEvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfuEUAf/ctluFVQKYmay0wtzHidgFA+7
PM7rs91XvfcyJOxW9ZU8LUV7Bjgb3IeJt+aFfweZPBQ4JuLS1JNXaPgF1O6kp24H
tn8AXMhqju4UP8F0n1Y1VmqR7tmzpRxOW+lQh/6LbG+CFbilFb7qIpmwUOqrV63t
xvkGQ1ffORFYro7BIFT61Y6c7amRYfKxV7OJgSd3rCWNHuPa+3NnsKUWciUYWGDk
iGPHisZ4Lj74pWgouud3SCUa3DVUJmiInipUWstJ8WpPGMpAzQtHp8+KtLqffbym
nvLGI5GzLh2OWK104ku181Dv6hUowugWR2XCE9tvpopTMhaW+/6Jt0RDsAvZxA==
=omlC
-----END PGP SIGNATURE-----

--wxDdMuZNg1r63Hyj--