So, if consensus shouldn't really be between the developers (which is
fine), should we empower users to control consensus? I've been working
on a fork framework anyway, which can support reasonably arbitrary
consensus changes (currently against block height, but moving towards
block time). Theoretically it could be modified to load consensus
parameters (which block size would have to be added to) from disk at
startup, rather than having them hard-coded.
Is that considered desirable? Will raise as a PR if so. If not, where do
we draw a line between developer and user consensus?
Ross
On 22/07/2015 17:52, Pieter Wuille via bitcoin-dev wrote:
Hello all,
I'd like to talk a bit about my view on the relation between the
Bitcoin Core project, and the consensus rules of Bitcoin.
I believe it is the responsibility of the maintainers/developers of
Bitcoin Core to create software which helps guarantee the security and
operation of the Bitcoin network.
In addition to normal software maintenance, bug fixes and performance
improvements, this includes DoS protection mechanism deemed necessary
to keep the network operational. Sometimes, such (per-node
configurable) policies have had economic impact, for example the dust
rule.
This also includes participating in discussions about consensus
changes, but not the responsibility to decide on them - only to
implement them when agreed upon. It would be irresponsible and
dangerous to the network and thus the users of the software to risk
forks, or to take a leading role in pushing dramatic changes. Bitcoin
Core developers obviously have the ability to make any changes to the
codebase or its releases, but it is still up to the community to
choose to run that code.
Some people have called the prospect of limited block space and the
development of a fee market a change in policy compared to the past. I
respectfully disagree with that. Bitcoin Core is not running the
Bitcoin economy, and its developers have no authority to set its
rules. Change in economics is always happening, and should be
expected. Worse, intervening in consensus changes would make the
ecosystem more dependent on the group taking that decision, not less.
So to point out what I consider obvious: if Bitcoin requires central
control over its rules by a group of developers, it is completely
uninteresting to me. Consensus changes should be done using consensus,
and the default in case of controversy is no change.
===
My personal opinion is that we - as a community - should indeed let a
fee market develop, and rather sooner than later, and that "kicking
the can down the road" is an incredibly dangerous precedent: if we are
willing to go through the risk of a hard fork because of a fear of
change of economics, then I believe that community is not ready to
deal with change at all. And some change is inevitable, at any block
size. Again, this does not mean the block size needs to be fixed
forever, but its intent should be growing with the evolution of
technology, not a panic reaction because a fear of change.
But I am not in any position to force this view. I only hope that
people don't think a fear of economic change is reason to give up
consensus.
--
Pieter
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
