MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Date: Sat, 01 Aug 2015 16:23:23 -0400
From: jl2012@xbt.hk
To: Michael Ruddy <mruddybtc@gmail.com>
In-Reply-To: <CABFP+yNgzNBtsfgHMNSJKpJmgD8jK13KRFP_P9+50ekiBoHfmQ@mail.gmail.com>
References: <20150723162321.Horde.bphh__8AhyXa_m-YAYpiyw1@server47.web-hosting.com>
	<CAE-z3OWZGsSS2s1OZU5ScH7C4BcOtCb9mcz62TA7HZQe_=y0uA@mail.gmail.com>
	<20150723192633.Horde.cGMZGo9Ji0-_9HZhcSUpww5@server47.web-hosting.com>
	<CABFP+yNgzNBtsfgHMNSJKpJmgD8jK13KRFP_P9+50ekiBoHfmQ@mail.gmail.com>
Message-ID: <2c9dd1c02fc550438d4bbab29e052f34@xbt.hk>
User-Agent: Roundcube Webmail/1.0.5
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP draft: Hardfork bit
Precedence: list

Although the chance is very slim, it is possible to have multiple 
hardforks sharing the same flag block. For example, different proposals 
may decide the flag time based on voting result and 2 proposals may have 
the same flag time just by chance. The coinbase message is to preclude 
any potential ambiguity. It also provides additional info to warning 
system of non-upgrading nodes.

If we are pretty sure that there won't be other hardfork proposal at the 
same time, the coinbase message may not be necessary. With some prior 
collaboration, this may also be avoided (e.g. no sharing flag block 
allowed as consensus rules of the hardforks)

The "version 0" idea is not compatible with the version bits voting 
system, so I have this hardfork bit BIP after thinking more carefully. 
Otherwise they are technically similar.

Michael Ruddy 於 2015-08-01 09:05 寫到:
>>> Ok, so set the bit and then include BIP-GIT-HASH of the canonical BIP 
>>> on
>>> github in the coinbase?
>> 
>> 
>> I guess the git hash is not known until the code is written? (correct 
>> me if
>> I'm wrong) As the coinbase message is consensus-critical, it must be 
>> part of
>> the source code and therefore you can't use any kind of hash of the 
>> code
>> itself (a chicken-and-egg problem)
>> 
> 
> I took Tier's comment to mean that the commit hash (taken from git) of
> the BIP for the particular hard fork being rolled out via your hard
> fork bit mechanism could be used in the coinbase.
> The commit for the BIP is separate from the commit for the code
> changes implementing it.
> 
> By using the commit hash of the BIP, it means that the BIP cannot
> specify itself what to put in the coinbase.
> I'd suggest that your hard fork bit proposal allows BIP authors to
> specify, within a 20 byte limit (to let them ripe160 a message or
> something), the unique value to use.
> This would be just as well and would allow the specific hard fork BIPs
> to be updated without having to make code changes (e.g.- for simple
> grammatical updates, post deployment clarification, etc...).
> 
> Perhaps more preferable, in order to keep the coinbases small, or, if
> you're worried about BIP authors using duplicate values, then just
> specify in your proposal that the coinbase message include
> "BIP<NUMBER>" as BIP numbers are not going to be reused. All you are
> trying to achieve is something that can be uniquely pattern matched.
> 
> Are the reasons for your use of the coinbase message 1) to guard
> against one or more hard forks piggy-backing on another's flag block,
> without prior collaboration, and 2) to have a nicer message in the
> alerting system? If so, you might want to spell that out in your
> proposal. At first, I was thinking that the coinbase thing was not
> entirely necessary since the possibility of multiple hard forks taking
> place concurrently is low. Multiple forking changes could be
> coordinated to all use the same possible voting mechanisms, median
> timestamp, and thus flag block. But if the concern is about competing
> hard forks where two or more forks abandon the original chain and
> attempt to use the same checkpoint block, then I can see why you'd
> need it.
> 
> I was reading this proposal alongside another of your messages
> (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009520.html)
> proposing a version 0 or even a >1MB block in the specific case of a
> block size limit hard fork. I can see the >1MB flag block creating DoS
> banning problems. That's more of a practical issue than a consensus
> issue due to the existing mono-culture of full nodes. So, currently a
>> 1MB flag block is not as appealing as a version 0 or this hard fork
> bit proposal. Besides the DoS ban, the >1MB proposal would mean that
> older nodes do not have the chance to notice a fork is happening (for
> alerting) as they would with a version 0 or hard fork bit.
> 
> A version 0 flag block would not be able to contain any transactions
> unless the flag block version was assumed to be that of the most
> recent version at the time. This is because we'd want to enforce the
> rules of the previous soft forks that had been locked in. Other than
> that, the version 0 idea seems pretty similar to the hard fork bit
> proposal because you need more context than just the block itself to
> determine if it's a valid flag block (and this extra context is
> probably not great, but I don't have a better idea right now).
> 
> Were those reasons part of why you progressed towards this hard fork
> bit proposal?