<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">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.<br>
<br>
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. <br>
<br>
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. <br>
<br>
Russ<br>
<br>
<br>
On 6/25/2015 4:05 PM, Tier Nolan wrote:<br>
</div>
<blockquote
cite="mid:CAE-z3OVOr=1e=_05Amzb9_JY70Zr+J5_ZTKArUzCFS2jPDAGHA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Thu, Jun 25, 2015 at 2:50 AM, Mark
Friedenbach <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:mark@friedenbach.org" target="_blank">mark@friedenbach.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div>
<div>
<div>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. </div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>There is no process for handling hard forks, which
aren't bug fixes.<br>
<br>
</div>
<div>Soft forks have a defined process of something like<br>
</div>
<div><br>
- BIP proposal + discussion<br>
</div>
<div>- Proposed code<br>
</div>
<div>- Dev acceptance<br>
</div>
<div>- Release<br>
</div>
<div>- Miner vote/acceptance<br>
<br>
</div>
<div>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.<br>
<br>
</div>
<div>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).<br>
<br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>Moving forward with agreement between all involved is
the recommended and desirable approach.<br>
<br>
</div>
<div>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.<br>
<br>
</div>
<div>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.<br>
<br>
</div>
<div>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?<br>
<br>
</div>
<div>There is clearly some kind of threshold that is
reasonable.<br>
<br>
</div>
<div>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?<br>
<br>
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.<br>
<br>
</div>
<div>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.<br>
<br>
</div>
<div>I wonder if a coin toss would be acceptable :). "Come
to an agreement or we decide by coin toss"<br>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
bitcoin-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>