1. BIP 148 was not possible without BIP 141.
How is that “stretching to have a connection”?
• BIP 141 defined SegWit itself. BIP 141 is the actual Segregated Witness proposal. It introduced the core consensus rule changes: separating signature data into a “witness” section, changing how transactions are serialized, replacing the block size limit with a block weight limit, and enabling future improvements like Lightning Network. Without these rules existing, there was nothing for BIP 148 to enforce.
• BIP 148 only enforces an existing deployment. BIP 148 is a User-Activated Soft Fork (UASF) that makes signaling for SegWit mandatory on a flag day (August 1, 2017). It does not define or create SegWit rules. It simply references the SegWit deployment that was already specified in BIP 9 (using bit 1) and forces nodes to reject blocks that do not signal support for it. That deployment was the one created by BIP 141.
• Technical dependency in the code. BIP 148’s logic checks whether blocks are signaling for the specific SegWit soft fork that BIP 141 defined. Without BIP 141 having been written, reviewed, and prepared as a soft fork, there would be no signaling bit, no SegWit consensus rules, and nothing for BIP 148’s rejection logic to activate.
• BIP 148’s own description confirms this. The BIP 148 document explicitly states it provides “flag day activation of the segregated witness BIP9 deployment known as segwit.” It builds directly on top of the work already done in BIP 141.
2.
Luke did many things to support the UASF itself beyond figuring out the code it relied on.
• Publicly stated that SegWit would activate by August 2017 either via miners (MASF) or users (BIP 148 UASF) if needed.
• Created KYCPoll, a sybil-resistant poll (using Coinbase KYC) showing strong community support for BIP 148 (~70% unconditional).
• Published an earlier Medium article (May 2017) titled “BIP148 and the risks it entails for you,” educating users on implications, risks, and what the UASF meant for node operators and the network.
• Wrote the later Medium guide “How you can help ensure BIP148 is a success,” with practical steps for proper node builds, economic enforcement, business outreach, and persistence.
• Maintained Bitcoin Knots with explicit BIP 148 support (marked “ BIP148”) and provided an Ubuntu PPA for easy installation of supporting nodes.
• Proposed a temporary service bit (1 << 27) for BIP148 signaling/support in a bitcoin-dev mailing list post to improve compatibility during the transition.
• Assisted in the careful deployment of BIP 148 nodes/software to help avoid a catastrophic chain split (per his professional summary).
• Hosted public charts on
luke.dashjr.org tracking SegWit signaling and node software adoption to monitor campaign progress.
• Actively posted on Twitter/X in 2017 defending BIP148 as a successful soft fork, clarifying misconceptions, warning about scam “148” tokens hijacking the name, and confirming SegWit activation thanks to it.
• Emphasized in discussions that economic activity on enforcing nodes matters more than raw node count for real rule enforcement.
• His work on BIP148 (alongside BIP8 concepts) was later acknowledged as a prerequisite in subsequent soft fork activation proposals (e.g., Taproot-related work).
• Later reflected positively on BIP148’s success in podcasts and posts, citing it as proof that UASFs work without chain splits and as precedent for user-driven enforcement.