From: "Jorge Timón" <jtimon@jtimon•cc>
To: Luke Dashjr <luke@dashjr•org>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>,
John Sacco <johnsock@gmail•com>
Subject: Re: [bitcoin-dev] BIP - Block size doubles at each reward halving with max block size of 32M
Date: Sun, 15 Nov 2015 13:16:56 +0100 [thread overview]
Message-ID: <CABm2gDryvFsnnV=8Bwc8mQX4JtU9_PgJ0EBhcYjpcSdXjV2_WA@mail.gmail.com> (raw)
In-Reply-To: <201511142127.53255.luke@dashjr.org>
On Sat, Nov 14, 2015 at 10:11 PM, Luke Dashjr <luke@dashjr•org> wrote:
> On Saturday, November 14, 2015 10:52:12 AM Jorge Timón via bitcoin-dev wrote:
>> Currently bip99 recommends 95% miner upgrade confirmation with version bits
>> (bip9) for uncontroversial hardforks just like it does for uncontroversial
>> softforks. It is true that in the case of hardforks miners don't decide and
>> it's the whole economy who has to upgrade before activation, but "the whole
>> economy" and "all users" includes miners, so why not use the only upgrade
>> confirmation mechanism that we have available?
>
> Actually, the economy does not necessarily include miners, and in fact the
> present miner community for the most part does not overlap significantly with
> economic activity.
Maybe we should define "the bitcoin economy" is first. In my
definition, miners are definitely part of the economy (and also users
of the system).
On Sat, Nov 14, 2015 at 10:27 PM, Luke Dashjr <luke@dashjr•org> wrote:
> On Saturday, November 14, 2015 9:15:07 PM Angel Leon wrote:
>> "the economy does not necessarily include miners"
>> so the money supply isn't part of the economy?
>
> Not in the context of economic majority deciding hardforks. After all, the
> outcome of the hardfork *determines* the money supply. So the former money
> supply not supporting the change would just mean they cease to be involved in
> that capacity. But even aside from that, the more relevant factor in terms of
> economic involvement is /acceptance/ of bitcoins as payment for real goods.
Miners accept bitcoins as payment for a real service (with real costs
like electricity) to the network: extending the longest valid chain
with their proof of work.
In the context of BIP99, there's no concept of "an economic majority"
deciding hardforks. Hardforks are either uncontroversial, in which
case BIP99 recommends 95% miner upgrade confirmation in addition to a
time threshold, or are schism hardforks (for example, an anti-miner
hardfork), in which case BIP99 recommends using a time threshold
alone. But no majority can force the dissenting users to use one
validation rule set or the other: users will always be free to run
whatever free software they like.
> And at the same time, miners also have a tendency to
> upgrade at a different rate than the economy.
That alone seems like a very good reason in favor to confirm that
miners have upgraded in addition to a minimal activation block median
time, not a reason against it
> It might make sense to
> incorporate a miner-trigger, but *only if* the flag is enabled in nodes by an
> option disabled by default, and the BIP clearly specifies that miners must not
> enable it until they perceive complete economic adoption of the change.
I'm not sure I understand this. The trigger mechanism must be uniform
for each rule change, it cannot be optionally different or consensus
can fail.
How are miners supposed to "perceive" adoption?
The time threshold must be set enough in the future to give users time
to upgrade. But we can perceive miners' adoption, so if the system
knows they haven't upgraded, it should wait for them to upgrade (it
would be nice to have an equivalent mechanism to wait for the rest of
the users, but unfortunately there's none).
Please, remember that this is in the context of uncontroversial
hardforks for which all users (including all miners) are expected to
upgrade to.
To reiterate, schism hardforks are treated differently and the miner
upgrade confirmation becomes completely irrelevant.
next prev parent reply other threads:[~2015-11-15 12:17 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-12 23:47 John Sacco
2015-11-13 2:56 ` Chun Wang
2015-11-13 3:37 ` John Sacco
2015-11-13 7:49 ` Btc Drak
2015-11-13 9:50 ` John Sacco
2015-11-13 10:52 ` Luke Dashjr
[not found] ` <1447430469019.e0ee1956@Nodemailer>
2015-11-13 22:28 ` Luke Dashjr
2015-11-14 0:02 ` digitsu
2015-11-14 9:31 ` Adam Back
2015-11-14 10:52 ` Jorge Timón
2015-11-14 21:11 ` Luke Dashjr
[not found] ` <CADZB0_Z3Kf4GW0VATjb10kJF0aFgyFOcqX_=y+LFoUpsi+TRUA@mail.gmail.com>
2015-11-14 21:27 ` Luke Dashjr
2015-11-15 12:16 ` Jorge Timón [this message]
[not found] ` <CABEog-XUNt9kDS7Mc0XYFjm5ePUT0m1YaAoG9VypTCiGLBongQ@mail.gmail.com>
2015-11-18 10:15 ` Jorge Timón
2015-11-13 6:39 ` Luke Dashjr
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='CABm2gDryvFsnnV=8Bwc8mQX4JtU9_PgJ0EBhcYjpcSdXjV2_WA@mail.gmail.com' \
--to=jtimon@jtimon$(echo .)cc \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=johnsock@gmail$(echo .)com \
--cc=luke@dashjr$(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