Pieter Wuille [ARCHIVE] on Nostr: π
Original date posted:2017-03-28 π Original message:On Tue, Mar 28, 2017 at ...
π
Original date posted:2017-03-28
π Original message:On Tue, Mar 28, 2017 at 12:56 PM, Paul Iverson via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> So I think Core can't decide on hard forks like this. It must be left up to
> the users. I think only choice is for Core to add a run-time option to allow
> node operators to increase block size limit, so that this very controversial
> decision is not coming from Core. It must come from the community.
Bitcoin Core's (nor any other software's) maintainers can already not
decide on a hard fork, and I keep being confused by the focus on Core
in this topic. Even if a hard forking change (or lack thereof) was
included into a new release, it is still up to the community to choose
to run the new software. Bitcoin Core has very intentionally no
auto-update feature, as the choice for what network rules to implement
must come from node operators, not developers. Ask yourself this: if a
new Bitcoin Core release would include a new rule that blacklists
<random famous person>'s coins. What do you think would happen? I hope
that people would refuse to update, and choose to run different full
node software.
Core is not special. It is one of many pieces of software that
implement today's Bitcoin consensus rules. If a hardfork is to take
place in a way that does not result in two currencies, it must be
clear that the entire ecosystem will adopt it. Bitcoin Core will not
merge any consensus changes that do not clearly satisfy that
criterion.
--
Pieter
Published at
2023-06-07 17:58:13Event JSON
{
"id": "0d3b189e50e64adcaf82833b2756acd08ff77327412e433203ca38b5f6ff2581",
"pubkey": "5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6",
"created_at": 1686160693,
"kind": 1,
"tags": [
[
"e",
"f66fb8ea0b053d3b896ce377aea38775ffc7975376c3ee96291861cf920b456b",
"",
"root"
],
[
"e",
"1b3d788670f370fb50c625cd3ecacf798250b64c402217291308bd3b92f1f638",
"",
"reply"
],
[
"p",
"5aec03abfeba7e49687161b8e2e0a1e7b197a77db10a7347ae147000dbcba7df"
]
],
"content": "π
Original date posted:2017-03-28\nπ Original message:On Tue, Mar 28, 2017 at 12:56 PM, Paul Iverson via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e So I think Core can't decide on hard forks like this. It must be left up to\n\u003e the users. I think only choice is for Core to add a run-time option to allow\n\u003e node operators to increase block size limit, so that this very controversial\n\u003e decision is not coming from Core. It must come from the community.\n\nBitcoin Core's (nor any other software's) maintainers can already not\ndecide on a hard fork, and I keep being confused by the focus on Core\nin this topic. Even if a hard forking change (or lack thereof) was\nincluded into a new release, it is still up to the community to choose\nto run the new software. Bitcoin Core has very intentionally no\nauto-update feature, as the choice for what network rules to implement\nmust come from node operators, not developers. Ask yourself this: if a\nnew Bitcoin Core release would include a new rule that blacklists\n\u003crandom famous person\u003e's coins. What do you think would happen? I hope\nthat people would refuse to update, and choose to run different full\nnode software.\n\nCore is not special. It is one of many pieces of software that\nimplement today's Bitcoin consensus rules. If a hardfork is to take\nplace in a way that does not result in two currencies, it must be\nclear that the entire ecosystem will adopt it. Bitcoin Core will not\nmerge any consensus changes that do not clearly satisfy that\ncriterion.\n\n-- \nPieter",
"sig": "d81a03483319ad4c11bcbf5090bb8534dc8522b87dd4d4bd749583cc06bde6c35dd7edeaf6c242aa03f74d4337971479ab17624311c9081bbf91ffec6ea53074"
}