* [bitcoin-dev] BIP148 temporary service bit (1 << 27)
@ 2017-06-19 19:26 Luke Dashjr
2017-06-19 19:46 ` Tom Zander
0 siblings, 1 reply; 3+ messages in thread
From: Luke Dashjr @ 2017-06-19 19:26 UTC (permalink / raw)
To: bitcoin-dev
To ease the transition to BIP148 and to minimise risks in the event miners
choose to perform a chain split attack, at least Bitcoin Knots will be using
the temporary service bit (1 << 27) to indicate BIP148 support.
Once the transition is complete, this will no longer be necessary, and the bit
will be (manually) returned for reuse.
I encourage other software implementing BIP148 (both full and light nodes) to
set and use this service bit to avoid network partitioning risks.
Luke
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoin-dev] BIP148 temporary service bit (1 << 27)
2017-06-19 19:26 [bitcoin-dev] BIP148 temporary service bit (1 << 27) Luke Dashjr
@ 2017-06-19 19:46 ` Tom Zander
2017-06-19 20:24 ` Mark Friedenbach
0 siblings, 1 reply; 3+ messages in thread
From: Tom Zander @ 2017-06-19 19:46 UTC (permalink / raw)
To: bitcoin-dev
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 miners
> choose to perform a chain split attack, at least Bitcoin Knots will be
> using the temporary service bit (1 << 27) to indicate BIP148 support.
>
> Once the transition is complete, this will no longer be necessary, and the
> bit will be (manually) returned for reuse.
>
> I encourage other software implementing BIP148 (both full and light nodes)
> to set and use this service bit to avoid network partitioning risks.
I'm curious what you action on the finding (or not) of a peer with this bit
set (or not).
Can you link to the github commit where you implemented this?
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoin-dev] BIP148 temporary service bit (1 << 27)
2017-06-19 19:46 ` Tom Zander
@ 2017-06-19 20:24 ` Mark Friedenbach
0 siblings, 0 replies; 3+ messages in thread
From: Mark Friedenbach @ 2017-06-19 20:24 UTC (permalink / raw)
To: Tom Zander, bitcoin-dev
It is essential that BIP-148 nodes connect to at least two other BIP-148 nodes to prevent a network partition in August 1st. The temporary service but is how such nodes are able to detect each other.
> On Jun 19, 2017, at 12:46 PM, Tom Zander via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>> 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 miners
>> choose to perform a chain split attack, at least Bitcoin Knots will be
>> using the temporary service bit (1 << 27) to indicate BIP148 support.
>>
>> Once the transition is complete, this will no longer be necessary, and the
>> bit will be (manually) returned for reuse.
>>
>> I encourage other software implementing BIP148 (both full and light nodes)
>> to set and use this service bit to avoid network partitioning risks.
>
> I'm curious what you action on the finding (or not) of a peer with this bit
> set (or not).
> Can you link to the github commit where you implemented this?
> --
> 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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2017-06-19 20:24 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-06-19 19:26 [bitcoin-dev] BIP148 temporary service bit (1 << 27) Luke Dashjr
2017-06-19 19:46 ` Tom Zander
2017-06-19 20:24 ` Mark Friedenbach
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox