Michael Ruddy [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-01 📝 Original message:>> Ok, so set the bit and ...

📅 Original date posted:2015-08-01
📝 Original message:>> 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?