From: Mark Friedenbach <mark@friedenbach.org>
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Date: Mon, 19 Jun 2017 13:24:25 -0700
Message-Id: <DAC56472-EF04-45FF-887B-2481B259E662@friedenbach.org>
References: <201706191926.25006.luke@dashjr.org> <3654399.ZkJ0Jlgova@cherry>
In-Reply-To: <3654399.ZkJ0Jlgova@cherry>
To: Tom Zander <tomz@freedommail.ch>,
 bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP148 temporary service bit (1 << 27)
Precedence: list

It is essential that BIP-148 nodes connect to at least two other BIP-148 nod=
es to prevent a network partition in August 1st. The temporary service but i=
s how such nodes are able to detect each other.

> On Jun 19, 2017, at 12:46 PM, Tom Zander via bitcoin-dev <bitcoin-dev@list=
s.linuxfoundation.org> wrote:
>=20
>> On Monday, 19 June 2017 21:26:22 CEST Luke Dashjr via bitcoin-dev wrote:
>> To ease the transition to BIP148 and to minimise risks in the event miner=
s
>> choose to perform a chain split attack, at least Bitcoin Knots will be
>> using the temporary service bit (1 << 27) to indicate BIP148 support.
>>=20
>> Once the transition is complete, this will no longer be necessary, and th=
e
>> bit will be (manually) returned for reuse.
>>=20
>> I encourage other software implementing BIP148 (both full and light nodes=
)
>> to set and use this service bit to avoid network partitioning risks.
>=20
> I'm curious what you action on the finding (or not) of a peer with this bi=
t=20
> set (or not).
> Can you link to the github commit where you implemented this?
> --=20
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev