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-----
next prev parent 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