Luke Dashjr [ARCHIVE] on Nostr: 📅 Original date posted:2020-01-12 📝 Original message:On Saturday 11 January ...
📅 Original date posted:2020-01-12
📝 Original message:On Saturday 11 January 2020 14:42:07 Anthony Towns wrote:
> the UASF approach had significant potential technical problems
> (potential for long reorgs, p2p network splits) that weren't
> resolved by the time it became active.
Long reorgs, only for old nodes, were a possibility, but not a problem.
The p2p network split issues WERE resolved well before activation.
(In fact, Bitcoin Knots still ships with the general p2p fixes.)
> neither
> BIP-148 or BIP-91 gained enough consensus to be supported in
> bitcoin core though
There was no measurable difference in community support between BIP148 and
Segwit itself, months before BIP148's activation. (There was about 20% that
indicated they would support BIP148 "only if Bitcoin Core releases it", which
IMO "counts" in this context.)
The only difference was in the opinions of developers. Basing the decision to
exclude BIP148 as even an *option* on this basis was IMO improper and
shouldn't be repeated. The community's readiness to switch to another
fork/build for UASFs is also valuable, but shouldn't be necessary.
Luke
📝 Original message:On Saturday 11 January 2020 14:42:07 Anthony Towns wrote:
> the UASF approach had significant potential technical problems
> (potential for long reorgs, p2p network splits) that weren't
> resolved by the time it became active.
Long reorgs, only for old nodes, were a possibility, but not a problem.
The p2p network split issues WERE resolved well before activation.
(In fact, Bitcoin Knots still ships with the general p2p fixes.)
> neither
> BIP-148 or BIP-91 gained enough consensus to be supported in
> bitcoin core though
There was no measurable difference in community support between BIP148 and
Segwit itself, months before BIP148's activation. (There was about 20% that
indicated they would support BIP148 "only if Bitcoin Core releases it", which
IMO "counts" in this context.)
The only difference was in the opinions of developers. Basing the decision to
exclude BIP148 as even an *option* on this basis was IMO improper and
shouldn't be repeated. The community's readiness to switch to another
fork/build for UASFs is also valuable, but shouldn't be necessary.
Luke