MIME-Version: 1.0
In-Reply-To: <20150723162321.Horde.bphh__8AhyXa_m-YAYpiyw1@server47.web-hosting.com>
References: <20150723162321.Horde.bphh__8AhyXa_m-YAYpiyw1@server47.web-hosting.com>
Date: Thu, 23 Jul 2015 18:59:40 +0100
Message-ID: <CAE-z3OWZGsSS2s1OZU5ScH7C4BcOtCb9mcz62TA7HZQe_=y0uA@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: "bitcoin-dev@lists.linuxfoundation.org"
	<bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a11c12436bf673e051b8ea6f3
Subject: Re: [bitcoin-dev] BIP draft: Hardfork bit
Precedence: list

--001a11c12436bf673e051b8ea6f3
Content-Type: text/plain; charset=UTF-8

On Thu, Jul 23, 2015 at 5:23 PM, jl2012 via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 2) Full nodes and SPV nodes following original consensus rules may not be
> aware of the deployment of a hardfork. They may stick to an
> economic-minority fork and unknowingly accept devalued legacy tokens.
>

This change means that they are kicked off the main chain immediately when
the fork activates.

The change is itself a hard fork.  Clients have be updated to get the
benefits.

3) In the case which the original consensus rules are also valid under the
> new consensus rules, users following the new chain may unexpectedly reorg
> back to the original chain if it grows faster than the new one. People may
> find their confirmed transactions becoming unconfirmed and lose money.
>

I don't understand the situation here.  Is the assumption of a group of
miners suddenly switching (for example, they realise that they didn't
intend to support the new rules)?

>
> Flag block is constructed in a way that nodes with the original consensus
> rules must reject. On the other hand, nodes with the new consensus rules
> must reject a block if it is not a flag block while it is supposed to be.
> To achieve these goals, the flag block must 1) have the hardfork bit
> setting to 1, 2) include a short predetermined unique description of the
> hardfork anywhere in its coinbase, and 3) follow any other rules required
> by the hardfork. If these conditions are not fully satisfied, upgraded
> nodes shall reject the block.
>

Ok, so set the bit and then include BIP-GIT-HASH of the canonical BIP on
github in the coinbase?

Since it is a hard fork, the version field could be completely
re-purposed.  Set the bit and add the BIP number as the lower bits in the
version field.  This lets SPV clients check if they know about the hard
fork.

There network protocol could be updated to add getdata support for asking
for a coinbase only merkleblock.  This would allow SPV clients to obtain
the coinbase.

Automatic warning system: When a flag block is found on the network, full
> nodes and SPV nodes should look into its coinbase. They should alert their
> users and/or stop accepting incoming transactions if it is an unknown
> hardfork. It should be noted that the warning system could become a DoS
> vector if the attacker is willing to give up the block reward. Therefore,
> the warning may be issued only if a few blocks are built on top of the flag
> block in a reasonable time frame. This will in turn increase the risk in
> case of a real planned hardfork so it is up to the wallet programmers to
> decide the optimal strategy. Human warning system (e.g. the emergency alert
> system in Bitcoin Core) could fill the gap.
>

If the rule was that hard forks only take effect 100 blocks after the flag
block, then this problem is eliminated.

Emergency hard forks may still have to take effect immediately though, so
it would have to be a custom not a rule.

--001a11c12436bf673e051b8ea6f3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Jul 23, 2015 at 5:23 PM, jl2012 via bitcoin-dev <span dir=3D"ltr">&lt;<=
a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">b=
itcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">
2) Full nodes and SPV nodes following original consensus rules may not be a=
ware of the deployment of a hardfork. They may stick to an economic-minorit=
y fork and unknowingly accept devalued legacy tokens.<br></blockquote><div>=
<br></div><div>This change means that they are kicked off the main chain im=
mediately when the fork activates.=C2=A0 <br><br></div><div>The change is i=
tself a hard fork.=C2=A0 Clients have be updated to get the benefits.<br></=
div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex">
3) In the case which the original consensus rules are also valid under the =
new consensus rules, users following the new chain may unexpectedly reorg b=
ack to the original chain if it grows faster than the new one. People may f=
ind their confirmed transactions becoming unconfirmed and lose money.<br></=
blockquote><div><br></div>I don&#39;t understand the situation here.=C2=A0 =
Is the assumption of a group of miners suddenly switching (for example, the=
y realise that they didn&#39;t intend to support the new rules)?<br></div><=
div class=3D"gmail_quote">=C2=A0<blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Flag block is constructed in a way that nodes with the original consensus r=
ules must reject. On the other hand, nodes with the new consensus rules mus=
t reject a block if it is not a flag block while it is supposed to be. To a=
chieve these goals, the flag block must 1) have the hardfork bit setting to=
 1, 2) include a short predetermined unique description of the hardfork any=
where in its coinbase, and 3) follow any other rules required by the hardfo=
rk. If these conditions are not fully satisfied, upgraded nodes shall rejec=
t the block.<br></blockquote><div><br></div><div>Ok, so set the bit and the=
n include BIP-GIT-HASH of the canonical BIP on github in the coinbase?<br><=
br></div><div>Since it is a hard fork, the version field could be completel=
y re-purposed.=C2=A0 Set the bit and add the BIP number as the lower bits i=
n the version field.=C2=A0 This lets SPV clients check if they know about t=
he hard fork.<br><br></div><div>There network protocol could be updated to =
add getdata support for asking for a coinbase only merkleblock.=C2=A0 This =
would allow SPV clients to obtain the coinbase.<br></div><div><br></div><di=
v></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex">Automatic warning system: When a fla=
g block is found on the network, full nodes and SPV nodes should look into =
its coinbase. They should alert their users and/or stop accepting incoming =
transactions if it is an unknown hardfork. It should be noted that the warn=
ing system could become a DoS vector if the attacker is willing to give up =
the block reward. Therefore, the warning may be issued only if a few blocks=
 are built on top of the flag block in a reasonable time frame. This will i=
n turn increase the risk in case of a real planned hardfork so it is up to =
the wallet programmers to decide the optimal strategy. Human warning system=
 (e.g. the emergency alert system in Bitcoin Core) could fill the gap.<br><=
/blockquote><div><br></div><div>If the rule was that hard forks only take e=
ffect 100 blocks after the flag block, then this problem is eliminated.<br>=
<br></div><div>Emergency hard forks may still have to take effect immediate=
ly though, so it would have to be a custom not a rule.</div></div></div></d=
iv>

--001a11c12436bf673e051b8ea6f3--