public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Eric Voskuil <eric@voskuil.org>
To: Luke Dashjr <luke@dashjr.org>, Peter Todd <pete@petertodd.org>,
	ZmnSCPxj <ZmnSCPxj@protonmail.com>,
	bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP: Block signal enforcement via tx fees
Date: Fri, 12 May 2017 20:26:08 -0700	[thread overview]
Message-ID: <c1a9b1d9-2810-0343-980d-45000c8600a8@voskuil.org> (raw)
In-Reply-To: <201705130049.33798.luke@dashjr.org>

-----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-----


  reply	other threads:[~2017-05-13  3:26 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 [this message]
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
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=c1a9b1d9-2810-0343-980d-45000c8600a8@voskuil.org \
    --to=eric@voskuil.org \
    --cc=ZmnSCPxj@protonmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=luke@dashjr.org \
    --cc=pete@petertodd.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