Message-ID: <55946AD9.3070300@riseup.net>
Date: Wed, 01 Jul 2015 15:34:01 -0700
From: odinn <odinn.cyberguerrilla@riseup.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Milly Bitcoin <milly@bitcoins.info>, bitcoin-dev@lists.linuxfoundation.org
References: <COL402-EAS109000AAC490BCF2DD69116CDAF0@phx.gbl>	<558B4632.8080504@bitcoins.info>	<CAOG=w-sxovqy0kDyBX=cx4CWWb=cd_F5bO3iH8ZBHsa0D_uK+A@mail.gmail.com>	<CAE-z3OVOr=1e=_05Amzb9_JY70Zr+J5_ZTKArUzCFS2jPDAGHA@mail.gmail.com>
	<558C9FE3.6000804@bitcoins.info>
In-Reply-To: <558C9FE3.6000804@bitcoins.info>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [bitcoin-dev] BIP Process and Votes
Precedence: list

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Possibly relevant to this discussion (though old)

https://gist.github.com/gavinandresen/2355445 (last changed in 2012 I
think?)

and

https://bitcoin.stackexchange.com/questions/30817/what-is-a-soft-fork
(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.
> 
> Russ
> 
> 
> On 6/25/2015 4:05 PM, Tier Nolan wrote:
>> On Thu, Jun 25, 2015 at 2:50 AM, Mark Friedenbach 
>> <mark@friedenbach.org <mailto:mark@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
> 

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVlGrZAAoJEGxwq/inSG8C2wYH/3VZgzpbJrgprqNMDwWsMoxx
DFbgjQfOrHbVvAQebSlcH1FXPnzVZZSbxMlQAbDXr4lpREvMPQiomixCmkTTepob
zKhJu/bGYgLVqcXSDYuJTwCKgHfzTj02Q8D8ViFZdsPOHLIuhcAAq+KgioUHH+Ps
v2kWA48ePTHVxqNd79S2CKjk5Gyo99YIMAjbQOuC6DbW/y1hNmQP7iQPn6UUe4pY
qyLLDa6ccKvJslq3chXGK/alhGHZ5lyEYZY43qiL9cBEgqEn6kHC5gveqQxvXMvj
rOoZbAKCAc9GdlhUplRt5MhF35FTFvbaBTAq07/95Xo4C8DIhmXesHgmPtc1OqI=
=n7Pa
-----END PGP SIGNATURE-----