fix: decipher reads TURBO flag from wrong variable, always reports turbo=true#83
Open
hans-crypto wants to merge 1 commit into
Open
fix: decipher reads TURBO flag from wrong variable, always reports turbo=true#83hans-crypto wants to merge 1 commit into
hans-crypto wants to merge 1 commit into
Conversation
hans-crypto
added a commit
to ordpool-space/ordpool-parser
that referenced
this pull request
May 13, 2026
…nestone.ts:123) Upstream Runestone.decipher reads `etching.turbo` from `etchingResult.set` inside a branch that's only entered when `etchingResult.set === true`, so every etching reports turbo=true regardless of the on-chain TURBO bit. Reference impl (ord, crates/ordinals/src/runestone.rs:86) takes turbo from `Flag::Turbo.take(&mut flags)`. Fix is one line in src/rune/src/runestone.ts -- read turboResult.set instead of etchingResult.set. Two real-mainnet regression tests in rune-parser.service.spec.ts under "Etching turbo flag", ground truth confirmed against ordinals.com via explorer.ordinalsbot.com/rune/<name>: Z*Z*Z*Z*Z*FEHU*Z*Z*Z*Z*Z (tx 2bb85f4b...) -> turbo=true DOG*GO*TO*THE*MOON (tx e7913408...) -> turbo=false Upstream PR filed: me-foundation/runestone-lib#83.
`Runestone.decipher` always reports `etching.turbo === true` for any
etching, regardless of whether the TURBO flag bit was actually set.
In `src/runestone.ts`, line 123 reads `etchingResult.set` to populate
`turbo`. But this line lives inside the `etchingFlag ? (() => {...})() : None`
lambda (line 65), which is only entered when `etchingResult.set === true`.
So `turbo` resolves to `true` unconditionally on every etching.
The reference implementation in ord
(crates/ordinals/src/runestone.rs:86) does:
turbo: Flag::Turbo.take(&mut flags)
i.e. pull the value from the TURBO flag check. The TS port already
computes `turboResult` correctly on line 122 — it just assigns the
wrong variable to `turbo`.
The bug is decode-only: the encode side (line 188) correctly emits the
TURBO bit from `etching.turbo`. So a runestone encoded with
`turbo: false` lands on chain correctly but decodes back as
`turbo: true`. Round-trip is broken.
Verified against on-chain ground truth from ordinals.com:
- Z•Z•Z•Z•Z•FEHU•Z•Z•Z•Z•Z (etched in block 840,000) -> turbo: true
- DOG•GO•TO•THE•MOON (etched in block 840,000) -> turbo: false
Before fix: both decode as turbo=true (DOG•GO•TO•THE•MOON wrong).
After fix: decode matches ord and ordinals.com on both.
Added two regression tests in test/runestone.test.ts mirroring the
style of `decipher_etching`: one constructs a runestone with only the
ETCHING flag (expect turbo=false), the other adds TURBO to the flags
mask (expect turbo=true). Both pass with the fix; the turbo=false
case is RED without it.
a80205a to
d5012a5
Compare
Author
|
My fork of runestone-lib has some on-chain testdata. The same fix lives downstream at ordpool-space/ordpool-parser@599f414 with two regression tests against real mainnet etchings from block 840,000. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Runestone.decipheralways reportsetching.turbo === truefor any etching, regardless of whether the TURBO flag bit was set on chain. The fix is one line.The bug
src/runestone.ts, line 123:This line lives inside the
etchingFlag ? (() => {...})() : Nonelambda (line 65), which is only entered whenetchingResult.set === true. Soturboresolves totrueunconditionally on every etching.The reference implementation in ord (
crates/ordinals/src/runestone.rs:86) does:The TS port already computes
turboResultcorrectly on line 122 — it just assigns the wrong variable.Direction of the bug
Decode-only. The encode side (line 188) correctly emits the TURBO bit from
etching.turbo, so a runestone encoded withturbo: falselands on chain correctly. But decoding it back readsturbo: true. Round-trip is broken in the decode direction.Quick verification
Both runes were etched in block 840,000
Z•Z•Z•Z•Z•FEHU•Z•Z•Z•Z•Z2bb85f4b00…7c69etruetrue✓ (coincidence)true✓DOG•GO•TO•THE•MOONe79134080a…a1375falsetrue✗false✓