To: Luke Dashjr <luke@dashjr.org>, Peter Todd <pete@petertodd.org>,
	ZmnSCPxj <ZmnSCPxj@protonmail.com>, bitcoin-dev@lists.linuxfoundation.org
References: <201705121922.57445.luke@dashjr.org>
	<20170512222214.GA4462@fedora-23-dvm>
	<201705130049.33798.luke@dashjr.org>
From: Eric Voskuil <eric@voskuil.org>
Message-ID: <c1a9b1d9-2810-0343-980d-45000c8600a8@voskuil.org>
Date: Fri, 12 May 2017 20:26:08 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
	Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <201705130049.33798.luke@dashjr.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [bitcoin-dev] BIP: Block signal enforcement via tx fees
Precedence: list

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

If people want to influence the decisions of miners, all they need to
do is mine.

I do not see why any person would want to pay, and then trust, another
to mine accordingly. Each person can mine and attain their level of
influence. This not only avoids the side payment, but earns the person
money.

There is nothing inherently wrong with paying people to run nodes or
signal "readiness", but there is no reason whatsoever to consider
these ideas beneficial from a personal/economic or
security/decentralization standpoint.

If you are not running a node you are not part of the economic
consensus. If you are not mining you have no say in transaction
ordering. The "solution" is both obvious and necessary to secure Bitcoin
.

If a person does not want to bother then he/she clearly does not have
a strong opinion. As developers we should be focused on reducing the
complexities of mining and of validation, not finding ways for people
to avoid participating in these necessarily distributed roles.

e

On 05/12/2017 05:49 PM, Luke Dashjr via bitcoin-dev 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.
> 
>> 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.
> 
>> 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?
> 
> On Friday 12 May 2017 10:17:30 PM ZmnSCPxj wrote:
>> Minor editorial nitpick, this paragraph is repeated, maybe one of
>> these should be Testnet?
>> 
>> For Bitcoin '''mainnet''', the BIP8 '''starttime''' will be TBD 
>> (Epoch timestamp TBD) and BIP8 '''timeout''' will be TBD (Epoch 
>> timestamp TBD).
>> 
>> For Bitcoin '''mainnet''', the BIP8 '''starttime''' will be TBD 
>> (Epoch timestamp TBD) and BIP8 '''timeout''' will be TBD (Epoch 
>> timestamp TBD).
> 
> Fixed, thanks.
> 
> Luke _______________________________________________ bitcoin-dev 
> mailing list bitcoin-dev@lists.linuxfoundation.org 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBCAAGBQJZFnzNAAoJEDzYwH8LXOFOlMsH/2Li7lDTr57EC2mSt4BuCf3Q
Q1sx21CBumm6OQKMxd207wgXTaxVJVmrGPXfJ6ZW8Bf+2tMKgc/LsZfzXdEo5+Fx
iTkdgJeW8QbKiEGzOFKMxWXH9jyCnd0WcDnKw/v7WqUhYfy2c9wz9RzCMY5iJqph
xd2+DeiEIjXIvE+l2TXGwjnB8Wp41QeY0I98kG3HHwNvNREbbGS/BjtLj5+eBygU
m+6dxkJoEttms31F47WFoZRzN7u5pe3BY5kDfZdVkbG7MOomSYwlhMvR3PtA1wrz
FeAUcHpp9MPj+qgHGwAGMfJiG/5WsVSrl/dJTm68zPOdwH60fMNNT/Srfbj1Ty8=
=9Xik
-----END PGP SIGNATURE-----