Tom Zander [ARCHIVE] on Nostr: 📅 Original date posted:2017-06-19 📝 Original message:On Monday, 19 June 2017 ...
📅 Original date posted:2017-06-19
📝 Original message: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
📝 Original message: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