From: Luke Dashjr <luke@dashjr•org>
To: Eric Voskuil <eric@voskuil•org>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP: Block signal enforcement via tx fees
Date: Sat, 13 May 2017 05:45:24 +0000 [thread overview]
Message-ID: <201705130545.25398.luke@dashjr.org> (raw)
In-Reply-To: <c1a9b1d9-2810-0343-980d-45000c8600a8@voskuil.org>
On Saturday 13 May 2017 3:26:08 AM Eric Voskuil wrote:
> If people want to influence the decisions of miners, all they need to
> do is mine.
Most people cannot mine except at a huge expense (profit is limited to few
people via monopoly and electric costs). But more importantly, the profits
from every miner you buy will go to pay for Bitmain growing their arsenal more
than enough to offset your influence.
Mining is simply broken at this point.
> 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.
Running a node and mining are two very different things.
> The argument fails to recognize that mining for one's self may (or may
> not) result in a net loss, but donating to a miner in the hope of some
> action is comparatively a total loss. One is an expense in exchange
> for the intended social outcome, and the other is payment for
> representative government.
>
> And in this form of representative government that you propose, if we
> assume that miners are somehow bound to honor the payments (votes), ...
First of all, this isn't donating to miners, but forbidding them from mining
your transaction (and thereby collecting your transaction fee) unless they
signal for the softfork.
Secondly, your argument here assumes miners are a government or control
Bitcoin in some way. This is not correct. Miners are entrusted with
enforcement of softforks *for old nodes only*, and therefore given the ability
to trigger activation of the new rules via signalling. But entrusting them
with this is NOT done by the system itself, but by the users, whose updated
nodes are the primary mechanism for enforcing softforks. So miners are in fact
already bound to honour the wishes of the greater economy, and their refusal
to do so is an attack on the network.
Luke
next prev parent reply other threads:[~2017-05-13 5:47 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-12 19:22 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 [this message]
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=201705130545.25398.luke@dashjr.org \
--to=luke@dashjr$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=eric@voskuil$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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