public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: odinn <odinn.cyberguerrilla@riseup.net>
To: Milly Bitcoin <milly@bitcoins.info>,
	bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP Process and Votes
Date: Wed, 01 Jul 2015 15:34:01 -0700	[thread overview]
Message-ID: <55946AD9.3070300@riseup.net> (raw)
In-Reply-To: <558C9FE3.6000804@bitcoins.info>

-----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-----


  reply	other threads:[~2015-07-01 22:34 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-24 23:41 [bitcoin-dev] BIP Process and Votes Raystonn
2015-06-24 23:49 ` Jeff Garzik
2015-06-25  0:11   ` Bryan Bishop
2015-06-25  0:21   ` Milly Bitcoin
2015-06-25  0:07 ` Milly Bitcoin
2015-06-25  1:50   ` Mark Friedenbach
2015-06-25  2:30     ` Alex Morcos
2015-06-25  2:34     ` Milly Bitcoin
2015-06-25  5:07       ` Jeff Garzik
2015-06-25  5:41         ` Milly Bitcoin
2015-06-25  6:06           ` Pindar Wong
2015-06-25  6:15             ` Mark Friedenbach
2015-06-25  6:16             ` Warren Togami Jr.
2015-06-25  6:27               ` Pindar Wong
2015-06-25  7:51         ` cipher anthem
2015-06-25 10:09           ` nxtchg
2015-06-25 12:42           ` Milly Bitcoin
2015-06-25 20:05     ` Tier Nolan
2015-06-26  0:42       ` Milly Bitcoin
2015-07-01 22:34         ` odinn [this message]
2015-06-25  3:42   ` Gareth Williams
2015-06-25  4:10     ` Milly Bitcoin
2015-06-25 13:36   ` s7r
2015-06-25 13:41     ` Eric Lombrozo
2015-06-25 13:51       ` s7r
2015-06-25 14:08       ` Milly Bitcoin
2015-06-25 17:03       ` Jeff Garzik
2015-06-25 17:29         ` Milly Bitcoin
2015-06-25  0:18 Raystonn
2015-06-25  3:00 Raystonn
2015-06-25  3:19 ` Milly Bitcoin
2015-06-26 11:13   ` Jorge Timón
2015-06-26 12:34     ` Milly Bitcoin
2015-06-27 11:28       ` Jorge Timón
2015-06-27 12:50         ` Milly Bitcoin
2015-06-28 12:30           ` Jorge Timón
2015-06-28 13:13             ` Milly Bitcoin
2015-06-28 15:35               ` Jorge Timón
2015-06-28 16:23                 ` Milly Bitcoin
2015-06-28 19:05                   ` Patrick Murck
2015-06-28 20:10                     ` Milly Bitcoin
2015-06-28 20:16                       ` Mark Friedenbach
2015-06-28 20:26                         ` Ricardo Filipe
2015-06-28 21:00                           ` Adam Back
2015-06-29  0:13                             ` Milly Bitcoin
2015-06-29  0:23                               ` Andrew Lapp
2015-06-29  1:11                                 ` Milly Bitcoin
2015-06-28 23:52                         ` Milly Bitcoin
2015-06-28 20:21                     ` NxtChg
2015-06-25 19:03 ` Tom Harding
2015-06-25  3:53 Raystonn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55946AD9.3070300@riseup.net \
    --to=odinn.cyberguerrilla@riseup.net \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=milly@bitcoins.info \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox