nostr:npub126ntw5mnermmj0znhjhgdk8lh2af72sm8qfzq48umdlnhaj9k...

npub1lnms53w04qt742qnhxag5d6awy7nz6055flnmjkr6jg39hm86dlq7arrnt
hex
fef0100b5ead606333fe169dffab951c54742b842716184bd56440d9b11c1528nevent
nevent1qqs0auqspd026crrx0lpd80l4w23c4r59wzzw9scf02kgsxekywp22qprpmhxue69uhhyetvv9ujuem4d36kwatvw5hx6mm9qgs0eac2gh86s9l24qfmnw52xawhz0f3d862yleaetpafygjmanaxlsr9hyddKind-1 (TextNote)
nostr:npub126ntw5mnermmj0znhjhgdk8lh2af72sm8qfzq48umdlnhaj9kuns3le9ll nostr:npub19z2uxvxz8uurr9kqa7vgmek6swurk3vra40ec8kmpf2eemx3lyqq6zfkd4 nostr:npub1lh273a4wpkup00stw8dzqjvvrqrfdrv2v3v4t8pynuezlfe5vjnsnaa9nk
I have been reviewing the Bitcoin Knots (pre-RDTS) package for StartOS and I think there is something important that needs clarification.
In the UI it appears installed as:
Bitcoin Knots (pre-RDTS)
but in the package source code #knotsprerdts:29.3:10 I can see that the manifest builds with:
VERSION: "29.3.knots20260508"
And the README itself says that this flavor:
“ships the same Bitcoin Knots binary as #knots without the Activate RDTS critical-task gate”.
In addition, the migration notes state that #knots and #knotsprerdts use the same upstream binary, and that switching to this flavor removes consensusrules=rdts.
The issue is that, on startup, the log still shows:
This version of Bitcoin Knots applies the BIP110 (RDTS) network upgrade
and also:
This node will STILL enforce them
This leads me to think that the flavor called pre-RDTS is not actually using a binary without RDTS, but rather the same RDTS binary, only without the critical confirmation task in StartOS.
If that is correct, the name pre-RDTS could be misleading: removing consensusrules=rdts would not prevent RDTS from being applied; it would only remove the explicit confirmation step.
Can Start9 clarify whether Bitcoin Knots (pre-RDTS) actually runs a binary without RDTS support, or whether it simply removes the activation gate/task?
I think it is important for users to know exactly which rules their node is enforcing.
Raw JSON
{
"kind": 1,
"id": "fef0100b5ead606333fe169dffab951c54742b842716184bd56440d9b11c1528",
"pubkey": "fcf70a45cfa817eaa813b9ba8a375d713d3169f4a27f3dcac3d49112df67d37e",
"created_at": 1780954132,
"tags": [
[
"t",
"knotsprerdts:29.3:10"
],
[
"t",
"knots"
],
[
"t",
"knots"
],
[
"t",
"knotsprerdts"
],
[
"p",
"fdd5e8f6ae0db817be0b71da20498c1806968d8a6459559c249f322fa73464a7"
],
[
"p",
"2895c330c23f383196c0ef988de6da83b83b4583ed5f9c1edb0a559cecd1f900"
],
[
"p",
"56a6b75373c8f7b93c53bcae86d8ffbaba9f2a1b38122054fcdb7f3bf645b727"
]
],
"content": "nostr:npub126ntw5mnermmj0znhjhgdk8lh2af72sm8qfzq48umdlnhaj9kuns3le9ll nostr:npub19z2uxvxz8uurr9kqa7vgmek6swurk3vra40ec8kmpf2eemx3lyqq6zfkd4 nostr:npub1lh273a4wpkup00stw8dzqjvvrqrfdrv2v3v4t8pynuezlfe5vjnsnaa9nk \n\nI have been reviewing the Bitcoin Knots (pre-RDTS) package for StartOS and I think there is something important that needs clarification.\n\nIn the UI it appears installed as:\n\n`Bitcoin Knots (pre-RDTS)`\n\nbut in the package source code `#knotsprerdts:29.3:10` I can see that the `manifest` builds with:\n\n`VERSION: \"29.3.knots20260508\"`\n\nAnd the README itself says that this flavor:\n\n\u003e “ships the same Bitcoin Knots binary as #knots without the Activate RDTS critical-task gate”.\n\nIn addition, the migration notes state that `#knots` and `#knotsprerdts` use the same upstream binary, and that switching to this flavor removes `consensusrules=rdts`.\n\nThe issue is that, on startup, the log still shows:\n\n`This version of Bitcoin Knots applies the BIP110 (RDTS) network upgrade`\n\nand also:\n\n`This node will STILL enforce them`\n\nThis leads me to think that the flavor called **pre-RDTS** is not actually using a binary without RDTS, but rather the same RDTS binary, only without the critical confirmation task in StartOS.\n\nIf that is correct, the name **pre-RDTS** could be misleading: removing `consensusrules=rdts` would not prevent RDTS from being applied; it would only remove the explicit confirmation step.\n\nCan Start9 clarify whether `Bitcoin Knots (pre-RDTS)` actually runs a binary without RDTS support, or whether it simply removes the activation gate/task?\n\nI think it is important for users to know exactly which rules their node is enforcing.",
"sig": "aa00949ef311880f55a3f27fe9a97774889213951fd544fb207fd662667de7cbd47066072718bb967f961ff93428c10390e9114c6d4018038ccc21fb6910acef"
}