That description makes sense. It also makes sense to separate out the
hard fork from the soft fork process. Right now some people want to
use the soft fork procedure for a hard fork simply because there is no
other way to do it.
I am under the impression that most users expect changes/improvements
that would require a hard fork so I think some kind of process needs to
be developed. Taking the responsibility off the shoulder of the core
maintainer also makes sense. The hard fork issue is too much of a
distraction for people trying to maintain the nuts and bolts of the
underlying system.
I saw a suggestion that regularly scheduled hard forks should be
planned. That seems to make sense so you would have some sort of
schedule where you would have cut off dates for hard-fork BIP
submissions. That way you avoid the debates over whether there should
be hard forks to what should be contained within the hard fork (if
needed). It makes sense to follow the BIP process as close as
possible. Possibly adding another step after "Dev acceptance" to
include input from others such as merchants/exchanges/miners/users. It
will only be an approximation of "decentralization" and the process
won't be perfect but if you want to move forward then you need some way
to do it.
Russ
On 6/25/2015 4:05 PM, Tier Nolan wrote:
On Thu, Jun 25, 2015 at 2:50 AM, Mark Friedenbach
<m...@friedenbach.org <mailto:m...@friedenbach.org>> wrote:
I'm sorry but this is absolutely not the case, Milly. The reason
that people get defensive is that we have a carefully constructed
process that does work (thank you very much!) and is well documented.
There is no process for handling hard forks, which aren't bug fixes.
Soft forks have a defined process of something like
- BIP proposal + discussion
- Proposed code
- Dev acceptance
- Release
- Miner vote/acceptance
The devs have a weak veto. If they refuse to move forward with
changes, miners could perform a soft fork on their own. They don't
want to do that, as it would be controversial and the devs know the
software better.
The miner veto is stronger (for soft forks) but not absolute. The
devs could checkpoint/blacklist a chain if miners implemented a fork
that wasn't acceptable (assuming the community backed them).
When ASICs arrived, it was pointed out by some that the devs could hit
back if ASICs weren't made publicly available. If they slightly
tweaked the hashing algorithm, then current generation of ASICs would
be useless. The potential threat may have acted as a disincentive
for ASIC manufacturers to use the ASICs themselves.
Moving forward with agreement between all involved is the recommended
and desirable approach.
Consensus between all parties is the goal but isn't absolutely
required. This escape valve is partly what makes consensus work. If
you dig your heels in, then the other side can bypass you, but they
have an incentive to try to convince you to compromise first. The
outcome is better if a middle ground can be found.
Hard forks are different. The "checks and balances" of weak vetoes
are not present. This means that things can devolve from consensus to
mutual veto. Consensus ceases to be a goal and becomes a requirement.
This is partly a reflection of the nature of hard forks. Everyone
needs to upgrade. On the other hand, if most of the various groups
upgrade, then users of the legacy software would have to upgrade or
get left behind. If 5% of the users decided not to upgrade, should
they be allowed to demand that nobody else does?
There is clearly some kind of threshold that is reasonable.
The fundamental problem is that there isn't agreement on what the
block size is. Is it equal in status to the 21 million BTC limit?
If Satoshi had said that 1MB was part of the definition of Bitcoin,
then I think people would accept it to the same extent as they accept
the 21 million coin limit. It might cause people to leave the coin
though.
It was intended to be temporary, but people have realized that it
might be a good idea to keep it. In effect both sides could argue
that they should be considered the status quo.
I wonder if a coin toss would be acceptable :). "Come to an agreement
or we decide by coin toss"
_______________________________________________
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
