From: "Jorge Timón" <jtimon@jtimon.cc>
To: Pieter Wuille <pieter.wuille@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
digitsu <jerry.d.chan@bittoku.co.jp>
Subject: Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard
Date: Sat, 26 Dec 2015 18:20:22 +0100 [thread overview]
Message-ID: <CABm2gDrpi=26o57-JHPbN5EPE9WKXO2bsqLv=aYHLtAO5y4WMA@mail.gmail.com> (raw)
In-Reply-To: <CAPg+sBiT5=ss9e=iac6J-A=85okF0zxMeV7H4z9-Qfx3CAWHXA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 940 bytes --]
On Dec 26, 2015 5:45 PM, "Pieter Wuille via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> My opinion is that the role of Bitcoin Core maintainers is judging
whether consensus for a hard fork exists, and is technically necessary and
safe. We don't need a hashpower vote to decide whether a hardfork is
accepted or not, we need to be sure that full noded will accept it, and
adopt it in time. A hashpower vote can still be used to be sure that miners
_also_ agree.
To clarify, that's the role of Bitcoin Core maintainers because they decide
what goes into Bitcoin Core, not because they decide the consensus rules of
Bitcoin. Other full node implementations (say, libbitcoin) will have to
decide on their own and Bitcoin Core mainteiners don't have any authority
over libbitcoin (or other alternative implementations). Nobody has such
authority (not even the creator of the system if he was still maintaining
Bitcoin Core).
[-- Attachment #2: Type: text/html, Size: 1075 bytes --]
next prev parent reply other threads:[~2015-12-26 17:20 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-16 14:53 [bitcoin-dev] Block size: It's economics & user preparation & moral hazard Jeff Garzik
2015-12-16 18:34 ` Pieter Wuille
2015-12-16 21:08 ` Jeff Garzik
2015-12-16 21:11 ` Pieter Wuille
2015-12-17 2:06 ` Jameson Lopp
2015-12-17 16:58 ` Tier Nolan
2015-12-17 19:44 ` Peter Todd
2015-12-18 5:23 ` Jorge Timón
2015-12-18 9:44 ` Tier Nolan
2015-12-16 21:24 ` Jorge Timón
2015-12-16 21:36 ` Jeff Garzik
2015-12-18 5:11 ` Jeff Garzik
2015-12-18 7:56 ` Pieter Wuille
2015-12-18 10:13 ` sickpig
2015-12-18 15:48 ` Pieter Wuille
2015-12-19 19:04 ` Dave Scotese
[not found] ` <751DFAA9-9013-4C54-BC1E-5F7ECB7469CC@gmail.com>
2015-12-26 16:44 ` Pieter Wuille
2015-12-26 17:20 ` Jorge Timón [this message]
2015-12-26 22:55 ` Jonathan Toomim
2015-12-26 23:01 ` Pieter Wuille
2015-12-26 23:07 ` Jonathan Toomim
2015-12-26 23:16 ` Pieter Wuille
2015-12-27 0:03 ` Jonathan Toomim
2015-12-26 23:15 ` Justus Ranvier
2015-12-27 0:13 ` Bryan Bishop
2015-12-27 0:33 ` Justus Ranvier
2015-12-18 13:56 ` Jeff Garzik
2015-12-23 6:26 ` Aaron Voisine
2015-12-16 18:36 ` jl2012
2015-12-16 22:27 ` Jeff Garzik
2015-12-17 6:12 ` Dave Scotese
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='CABm2gDrpi=26o57-JHPbN5EPE9WKXO2bsqLv=aYHLtAO5y4WMA@mail.gmail.com' \
--to=jtimon@jtimon.cc \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=jerry.d.chan@bittoku.co.jp \
--cc=pieter.wuille@gmail.com \
/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