Date: Sat, 13 May 2017 08:48:48 -0400
From: Peter Todd <pete@petertodd.org>
To: Luke Dashjr <luke@dashjr.org>
Message-ID: <20170513124848.GC8884@fedora-23-dvm>
References: <201705121922.57445.luke@dashjr.org>
	<20170512222214.GA4462@fedora-23-dvm>
	<201705130049.33798.luke@dashjr.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="GZVR6ND4mMseVXL/"
Content-Disposition: inline
In-Reply-To: <201705130049.33798.luke@dashjr.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP: Block signal enforcement via tx fees
Precedence: list


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

On Sat, May 13, 2017 at 12:49:33AM +0000, Luke Dashjr wrote:
> On Friday 12 May 2017 10:22:14 PM Peter Todd wrote:
> > nVersion signaling is already technically unenforceable, in the sense t=
hat
> > we don't have good ways of ensuring miners actually adopt the rules
> > they're claiming to signal. Equally, it's users who ultimately adopt
> > rules, not miners, and attempting to pay miners to signal certain bits
> > will further confuse this point.
>=20
> This BIP doesn't change that. Enforcement remains primarily by users.

I'm not arguing that it changes that; I'm arguing that it further confuses =
the
situation.

> > Quite likely the outcome of users trying to anonymously pay anonymous
> > miners to signal certain bits will be the complete breakdown of the
> > honesty of the nVersion signalling system, currently enforced only by
> > "gentlemans agreement".
>=20
> You assume users will pay for signalling of softforks prematurely. So lon=
g as=20
> it waits until deployment of the softfork is widespread, this risk is min=
imal.=20
> At worst, it creates risks similar to a UASF. So long as UASF is the=20
> alternative, this way seems strictly better.

I think you're assuming that the users paying for soft-fork signalling will
represent an economic majority; that's not necessarily the case.

For example, if miners decide there's no downside to false signalling, they=
 may
take the extra fees provided by 1% of the users paying to signal a fork, wh=
ile
the other 99% don't participate, resulting in a situation where we have blo=
cks
violating the nVersion protocol, and an unknown % of that 99% rejecting tho=
se
blocks. At best that'd be no worse than a UASF, and at wost you're wrecked =
the
validity of the nVersion "gentlemans agreement"

> > Also, as an aside, this "specification" again shows the inadequacy and
> > unreadability of English language specifications. I'd strongly suggest =
you
> > delete it and instead mark the "reference implementation" as the
> > specification.
>=20
> How so?

Just read it: you have ten separate lines of dense English text describing
something that could have been specified instead by ten lines of much more
formally defined C++. In particular, note how many of those lines of English
text refer to C++ code anyway, like the sentence "minimal-length 40-bit
CScriptNum"

I don't want to have to learn another language - formally defined English t=
hat
still fails to be formally defined - just to read Bitcoin's specification.

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

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

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

iQEcBAEBCAAGBQJZFwCvAAoJECSBQD2l8JH7BvoH/3FyKbT2CB4HCYFMtJc4uaOm
IfSgU+EKGJYs37nnQyaovBCUeTory/1rB6hfy0T4e9aOzLuqdtsgP+qIPRrvJ0xy
q+/rIrSM7l2w0hCE56hz0QW7OgW6og5vFq3U5GNONXEMBD2uwFSE26BVB5h2yU41
V4WVEYqsELnoYEO1ZB32Hsk+nxiM4GZ2IXObnxnNG70eM/YBdMgIszjzMwMvoP+m
JHwSJpegCFl1rQCWOsL94L7BkaZ/9p2YWLwirtVKLRzUAFS0MHDtoRErmuGETZ0X
ghdBBnUR5kGimzLDKG1H0lsYEwI8Y9ToDmrnd6eB+jnm1AdsPocSIinhj2HI+BQ=
=/J+C
-----END PGP SIGNATURE-----

--GZVR6ND4mMseVXL/--