[bitcoin-dev] BIP Process and Votes
odinn.cyberguerrilla at riseup.net
Wed Jul 1 22:34:01 UTC 2015
-----BEGIN PGP SIGNED MESSAGE-----
Possibly relevant to this discussion (though old)
https://gist.github.com/gavinandresen/2355445 (last changed in 2012 I
(which cites gavin's gist shown above)
On 06/25/2015 05:42 PM, Milly Bitcoin wrote:
> 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.
> On 6/25/2015 4:05 PM, Tier Nolan wrote:
>> On Thu, Jun 25, 2015 at 2:50 AM, Mark Friedenbach
>> <mark at friedenbach.org <mailto:mark at 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
>> 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
>> 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
>> 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
>> 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
>> 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 at lists.linuxfoundation.org
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at lists.linuxfoundation.org
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
-----END PGP SIGNATURE-----
More information about the bitcoin-dev