Yeah, I think Gavin left the space in 2016, he should definitely show up as retired

How are "Retired", "Fading", and "Steady" determined?

E.g., in this screenshot, Christian Decker is marked as retired, but actively working on CLN,

Nicolas Dorier is marked retired, but maintainer of BTCPay Server and NBitcoin,

I haven’t really seen anything from Aaron Voisine in forever (had a hard time reaching him regarding some of his BIPs), while he’s marked as "Fading",

and Brandon Black is marked as retired, but has contributed review to the BIPs repository (and Optech) this year.

Just saw, that Steven Roose is also marked as retired, but he co-authored a BIP this year and is working on one of the Ark projects.

Interesting idea! Glancing at this, the same separation should then maybe also be applied to the other metrics then. E.g., PRs Reviewed.

Asking questions answered 12 years ago already ;)

https://nakamotoinstitute.org/mempool/everyones-a-scammer/

Maybe you could instruct your LLM to answer those questions.

This should read: Only miners would …have to upgrade…

Sheesh. I should stop moving around sentences after throwing together a first draft for a comment.

It is, in the sense that it was also Portuguese sailors who gave Taiwan’s main island that name, presumably because the Ilha Formosa was easy on their eyes. ;)

Some such cross-camp conversations happened, e.g., on the mailing list, various Bitcoin Core pull requests, BIPs PRs, podcasts, Delving Bitcoin, and other social media.

AFAICT, the conversations largely failed at the stage of establishing sufficient shared facts to have a conversation. E.g., while neither group seems to be fond of NFTs, they disagree on whether spam constitutes a significant harm. This is considered obvious by one side and speculative by the other. There are a number of other such disagreements that led to most arguments being considered invalid by the respective other side. Ultimately, the positions seem completely irreconcilable, so the split is bound to happen.

Everybody is running the “URSF software” already.

Assuming that support remains similarly marginal as it is (1/552 blocks this difficulty period so far), Bitcoin will likely find many blocks before RDTS finds its first block in the mandatory signaling period.

If Bitcoin is dozens of blocks ahead when the first RDTS block is proffered, a reorg will be unacceptable to the Bitcoin ecosystem, and power users (incl. LSPs, miner that found blocks, businesses that accepted payments, etc.) may as well call invalidateblock <RDTS_block_hash>, and move on with their lives.

The difficulty can adjust up to a factor of 4 in either direction. If they activated with 1% of the hashrate (and they maintained the same hashrate indefinitely), they’d take about 200 weeks to reach the first difficulty adjustment, then 50 weeks to reach the next, then 12.5 weeks to reach the third, then 3.125 weeks for the fourth, then they’d be back to 10 minute blocks. So, it would only take an expected 265.625 weeks or slightly over 5 years to get back to the normal block cadence. — Good thing many RDTS proponents seem to be open to a blockspace reduction. ;)

Mandatory signaling starting at the beginning of a difficulty period is pretty detrimental to a soft fork attempt with such low hashrate support. A bunch of RDTS proponents have lately been mentioning that they’d be open to “firing the miners if the majority of them is malicious”, so it sounds like they are seeding support for a proof-of-work change when their mandatory signaling period goes as poorly as expected.

I think this is a terminology issue rather than a disagreement. It’s a soft fork. Existing nodes would not need to upgrade to remain interoperable with BIP110, if it got adopted. If BIP110 had majority support, nodes would follow along just fine. Only miners would, but that’s normal for soft forks. Soft forks enacted by a hashrate minority do lead to a permanent chainsplit.

^{Image from this explanation on BSE}

The BIP110 nodes will reject non-conforming nodes after the August fork date.

Usually nodes would disconnect peers that offer an invalid block, so I suspected the same in the past, but some RDTS proponent informed me that RDTS explicitly allows peers to offer blocks that would be valid under the old rules, so I don’t think the RDTS nodes will disconnect from the P2P network immediately.

Then for good measure, they hard-fork themselves again when they revert their previously added filtering rules.

I disagree with this characterization. Adding more restrictions is a soft fork. Adding restrictions with a limited time frame is still a restriction, not a loosening of rules.

whether who -> who
almost have -> almost half

Yeah, I also noticed this odd conflation in the OP. Clearly, the rules proposed by BIP 110 constitute a soft fork. However, with the minority hashrate in support the implementing nodes would likely be permanently split from the best chain onto their own chaintip. Since the difficulty would be prohibitive at their current support level (let’s generously say 1% ~> 200 weeks to the first difficulty adjustment), if they double down, they’d likely then follow up with a hardfork that either reduces the difficulty or changes the PoW mechanism.

That's it. What do you think is bad here ?

Thanks for asking.

1. New output scriptPubKeys exceeding 34 bytes are invalid, unless the first opcode is OP_RETURN, in which case up to 83 bytes are valid.

RDTS only allows one OP_RETURN output, so that would mean that any systems that embed more than 80 bytes of data in outputs would be forced to use unspendable payment outputs for anything in excess of 80 bytes (like the example that started this debate). Also, what if we want to introduce a PQ-safe output scheme next year that needs more than 34 bytes in its output script?

2. OP_PUSHDATA* payloads and script argument witness items exceeding 256 bytes are invalid, except for the redeemScript push in BIP16 scriptSigs.

Seems pointless for reducing data insertion as stack items are already limited to 520 bytes and multiple 256-byte pushes would still be allowed, otoh, such a low limit would probably be incompatible with some future soft forks, e.g., PQ-signature schemes which might need drastically larger public keys and signatures.

3. Spending undefined witness (or Tapleaf) versions (ie, not Witness v0/BIP 141, Taproot/BIP 341, or P2A) is invalid. (Creating outputs with undefined witness versions is still valid.)

Breaks our upgrade hooks for introducing new output types, e.g., if the P2MR proposal were to gain steam in the next ~14 months.

4. Witness stacks with a Taproot annex are invalid.

Breaks another upgrade hook, and is unused.

5. Taproot control blocks larger than 257 bytes (a merkle tree with 128 script leaves) are invalid.

It can only have 128 leaves if all of them are at a depth of 7, which makes the control block 258 bytes. Most P2TR script trees are unbalanced binary trees (think Huffman trees) to make the more likely leaf scripts have smaller control blocks.
So, we don’t need OP_IF, because we can split up scripts into multiple leaves, but then we also limit script trees to a depth of 7? Seems unnecessary and dumb, but most people can probably make due with depth 7. This might be the least offensive rule, yet.

6. Tapscripts including OP_SUCCESS* opcodes anywhere (even unexecuted) are invalid.

Breaks more upgrade hooks, in a time when some covenant proposals actually had been gaining a little momentum.

7. Tapscripts executing the OP_IF or OP_NOTIF instruction (regardless of result) are invalid.

Making OP_IF invalid is an absolute no-go. Beyond if(…) being the most basic conditional statement in every programming language under the sun, there are a number of projects that have rolled out Miniscript support in mainnet, and Miniscript is known to generate leaf scripts with OP_IF in some circumstances. Since script leaves do not become visible unless used, and most P2TR outputs with more complex spending conditions have an “everyone signs” keypath fallback, it cannot be ruled out that users have deployed wallet patterns based on OP_IF to mainnet. Since we cannot determine whether who such people might be and therefore cannot ensure that all such people are aware, have updated their software, and have migrated away from such wallet patterns, and it generally cannot be prevented that senders reuse past scripts that used such a pattern, this must be considered to break user space on principle. RDTS proponents have argued that this is acceptable, Bitcoin protocol designers generally seem to consider this indefensible.

Some further thoughts:

1. The above is just taking the proposed consensus rules at face value and assuming the soft fork is actually temporary. However, when asked how proponents expect to proceed after BIP110 expires, they frequently float that once RDTS is activated, they would lobby for the rules to become permanent. That would obviously be disastrous, because it would remove almost all upgrade hooks protocol developers have labored to create in the past dozen years and would permanently disenfranchise any affected users.
2. 55% activation threshold is completely irresponsible.
3. Going for mandatory activation on a first activation attempt, especially for an idea that is so obviously controversial, forces a game of chicken that undermines any potential for charitable interpretation.

The entire soft fork is based on only processing the first part of what protocol developers have been telling filter proponents for years: policy can be undermined by a tolerant minority, so it is infeasible to establish more strict policies against collaborating senders and miners—transaction patterns can only be effectively forbidden at the consensus level. However, consensus changes move slowly enough that data enthusiasts can easily preempt new consensus rules if their fad hasn’t jumped the shark by itself by then.

RDTS forbids inscriptions and large OP_RETURNs. Meanwhile, inscriptions have diminished to a minuscule portion of blockspace and large OP_RETURNs are basically non-existent, while still almost have the blockspace is going towards other NFT transactions (now based on Runes which RDTS will accept). Numerous ways to embed data even under RDTS rules have been demonstrated.

When someone proposes a consensus change, it is on them to convince the ecosystem that the benefits are worth the cost. The default position is that the status quo is maintained. This consensus change proposal is poorly motivated, recklessly designed, and irresponsibly championed. The doubtful benefits drastically fall short of the downsides and costs.

Regarding Luke’s merge commits, it looks like the same thing happened there that also happened to Jonas. I tracked down there of his merge commits. One was the last commit in the PR https://github.com/bitcoin/bitcoin/pull/7192, another was the second in https://github.com/bitcoin/bitcoin/pull/7192, the third was the fourth in https://github.com/bitcoin/bitcoin/pull/505. The first two PRs later got merged by Mara van der Laan, the third by Gavin Andresen.

On Strategic Maintainers: In the UI, I use dotted/hollow bars for Cory Fields, Carl Dong, and Sebastian Kung (sedited) from 2019–2025. This visually distinguishes that they were Strategic Maintainers (e.g., maintaining the build system, security, or Guix) but did not hold keys to merge into the master branch.

At least among Bitcoin Core contributors the term maintainer has a very specific meaning. I’m aware that these three led big projects, but I haven’t heard the term maintainer in that context before. Maybe a different term such as "project lead" would fit better?

Sorry, I made a mistake with my search parameters regarding svanstaa, I agree it’s his first PR he authored.

Yeah, secp256k1 and bitcoin-core/gui would make sense to include.

Looking around on the website a bit, I noticed that the list of maintainers seems to have some quirks. Here are a few things I noticed:

• Luke Dashjr, Cory Fields, and Carl Dong were never Bitcoin Core maintainers.
• Sebastian Kung only became a maintainer this year
• Ava Chow has been a maintainer since 2021
• Marco Falke was a maintainer from 2016–2023, not 2015–present
• AFAIK, Jonas Schnelli started in 2015, not 2013
• Gavin Andresen was maintainer until 2016, not 2015

This list should be accurate and also has sources for most dates: https://bitcoin.stackexchange.com/a/88649/5406

Thanks, that’s cool! One nit: I noticed that you list Sebastian van Staa as a new contributor (svanstaa), but I think he has had several PRs merged in Bitcoin Core (around 5 or 6?), there might be an issue there.

I may have cut off the id, https://podcasts.apple.com/zw/podcast/honigdachs/id1099608079 works.

oh oops, I just have broken the link when I formatted it

Sorry, I didn’t mean that you missed it, it seemed pretty obvious that you were only looking at English podcasts. I just thought it was an interesting tidbit to share.