The new draft of the BIP has been posted to the bitcoindev mailing list:

https://groups.google.com/g/bitcoindev/c/nOZim6FbuF8/m/d4tkNi0DAQAJ

The code has been published here:

https://github.com/bitcoinknots/bitcoin/compare/29.x-knots...UASF:bitcoin:29.2.knots20251010+BIP444?expand=1

I'm looking forward to hearing your feedback.

Reply to this note

Please Login to reply.

Discussion

I believe there is no compelling reason to remove the 'Reactive' softfork deployment method on the pretense of building consensus. Quite the opposite, the existence of the 'Reactive' option acts as an additional lever, actually leading to greater consensus.

I think the same. Stop making compromises with clearly bad actors.

Perhaps he compromise is not as much for the bad actors as it is for more of the middle?

I dunno...

I dunno either. The problem with fixing decentralised protocols is that your solution can’t be perfect if you want to make it go through. I think that’s an attack vector on itself.

nevent1qqszcu3y9x929p5p8qtajyam6wtgzu8lsust2age8t0dlk4mzpxy5xszvwldc

Excellent.

Thanks nostr:nprofile1qqsw3p5pela795rxxff34kgfafsaawhnkqp8ehmgm2my49dgx9fjclcprpmhxue69uhhyetvv9ujuempwd6x2ct6dyhxuet5qyt8wumn8ghj7ct5d3shxtnwdaehgu3wd3skueq9npjah 🫡

I still think the reactive method shouldn’t be removed from the BIP. It’s a fallback if plan A fails, and I get the sense it’s the one that unsettles the bad actors the most.

nostr:nevent1qqsykd7h7pke9rm567gamca0uh9qjds5u4lc996qrrhz0a08z790m5spzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgevv2td