public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd.org>
To: Luke Dashjr <luke@dashjr.org>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP: Block signal enforcement via tx fees
Date: Sat, 13 May 2017 08:48:48 -0400	[thread overview]
Message-ID: <20170513124848.GC8884@fedora-23-dvm> (raw)
In-Reply-To: <201705130049.33798.luke@dashjr.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 --]

  parent reply	other threads:[~2017-05-13 12:49 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-12 19:22 [bitcoin-dev] BIP: Block signal enforcement via tx fees Luke Dashjr
2017-05-12 22:17 ` ZmnSCPxj
2017-05-12 22:22 ` Peter Todd
2017-05-13  0:49   ` Luke Dashjr
2017-05-13  3:26     ` Eric Voskuil
2017-05-13  3:54       ` ZmnSCPxj
2017-05-13  5:36         ` Eric Voskuil
2017-05-13  5:45       ` Luke Dashjr
2017-05-13  6:43         ` Eric Voskuil
2017-05-13 12:48     ` Peter Todd [this message]
2017-05-13 16:42       ` Luke Dashjr
2017-05-13  4:23 ` Russell O'Connor
2017-05-13  5:26   ` Luke Dashjr
2017-05-13 17:11     ` Russell O'Connor
2017-05-15  1:14       ` Rusty Russell
2017-05-20  5:05       ` Anthony Towns
2017-05-14 12:18 ` ZmnSCPxj

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170513124848.GC8884@fedora-23-dvm \
    --to=pete@petertodd.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=luke@dashjr.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox