Re: [bitcoin-dev] BIP: Block signal enforcement via tx fees

[Peter Todd <pete@petertodd.org>]

[-- Attachment #1: Type: text/plain, Size: 2565 bytes --]

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 that
> > 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.
> 
> 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".
> 
> You assume users will pay for signalling of softforks prematurely. So long as 
> it waits until deployment of the softfork is widespread, this risk is minimal. 
> At worst, it creates risks similar to a UASF. So long as UASF is the 
> 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, while
the other 99% don't participate, resulting in a situation where we have blocks
violating the nVersion protocol, and an unknown % of that 99% rejecting those
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.
> 
> 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 that
still fails to be formally defined - just to read Bitcoin's specification.

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]