Addresses / Pair 06 of 41
Did the set move, or did your copy slip
Your saved address no longer matches what is in front of you. Before deciding the market moved, check whether the thing you saved was ever a valid address in the first place.
One string, two ways of being wrong
The published set is different now
The set being published has been updated. Strings drop off it, strings appear on it, and a note you wrote months ago has no way of following that on its own.
Your record is damaged
Somewhere between the screen and your file, characters were lost, doubled, transposed, or read as the wrong glyph. The set never moved at all. Your copy of it did.
Both arrive at you as the same event: a string in your hand that does not match a string on your screen. From there the two stories are wildly different in what they ask of you, and only one of them involves going anywhere.
People reach for the changed-set story first, and it is easy to see why. It is external, it is dramatic, and it flatters your copying. Admitting that a character went astray while you were pasting feels like admitting to being careless, which nobody enjoys at the moment they are trying to get somewhere.
Counting before comparing
Check the string is even possible
Count to fifty-six, then scan for 0, 1, 8 and 9. Onion addresses use base32, which is a to z and 2 to 7 only, so any of those four digits means the string was damaged rather than replaced.
- Count the characters before .onion. There have to be exactly fifty-six, and a wrong count settles the matter on its own.
- Scan for 0, 1, 8 and 9. None of them can appear in a valid address. A zero means you captured an o, a one usually means an l or an i.
- Look for spaces, line breaks and stray punctuation that came along with the paste. Case makes no difference to the client, but a space certainly does.
- Only when the string is exactly fifty-six legal characters is it worth asking whether the published set actually moved.
What each case asks of you
- Length first, always. A wrong length is a wrong copy, and no amount of careful comparison afterwards will rescue it.
- Then the alphabet. An illegal character means the same thing as a wrong length, and it is faster to spot.
- Then position. If your string agrees with a published one nearly everywhere and differs in one or two places, you damaged it. Two independent keys do not produce strings that happen to agree in fifty-four positions.
- Then wholesale difference. A legal string sharing nothing with the current set is either an address that was genuinely dropped or one that was never theirs, which is a separate pair.
That order saves you from the common trap, which is comparing character by character against a string that could never have been valid. Once you know the length is wrong, comparison is wasted effort, and wasted effort at this point tends to end with you deciding something has changed.
The cost of assuming a move
- If you treat a changed list as a copying error
- You recopy a string that genuinely is no longer published, get the same result, and blame your hands for a while. The bill is time and mild irritation.
- If you treat a copying error as a changed list
- You decide the market has moved, go looking for a fresh set, and accept whatever the first place you land on happens to offer. That is how people end up with a string somebody wanted them to have.
Both readings end with you doing something, and only one of the two somethings can hurt. Checking your own copy costs nothing and can be done without leaving the room. Going looking for a new set means trusting a new source, and new sources found in a hurry are the weakest link in this entire business. The costs table puts this pair beside the others, and the pattern holds throughout.
Fixing your copy or your source
- If the list changed
- Take the set fresh from somewhere the market controls and replace your note as a whole rather than editing individual lines. Write the date next to it so the next version of you knows how old it is.
- If your copy is wrong
- Recopy from the source in a single action and paste it in a single action. Then compare the middle of the result against the source before you save anything.
Questions readers send about this pair
Can an onion address contain the digit 0 or 1?
No. Base32 as used here is the letters a to z and the digits 2 to 7, nothing else. A zero or a one in your string means a letter was misread on the way into your file.
How often do published sets actually change?
Often enough that an old note is worth doubting, and rarely enough that a mismatch is much more likely to be your copy. Check the copy first since it is free, then consider the set.
Does capitalisation matter?
Not to the client, which treats the string case-insensitively. It matters to you only in that a copy with odd capitalisation is a hint that the string passed through something that reformatted it, and reformatting loses characters.