Specifiers were always intended to be human-readable IDs. This codifies that by escaping non-alphanumeric specifiers during marshaling. Alphanumeric specifiers are marshaled exactly the same as before.
Non-alphanumeric specifiers are fairly rare. The most common offending character is " ", which shows up in v1 specifiers like "siacoin output". Also, an early version of the RHP used raw integers in some of its RPC IDs (e.g. "RPCDownload\x02"), but those RPCs have been obsolete for many years at this point.
Specifiers are primarily seen in two places: UnlockKey algorithms in transaction inputs, and RPC IDs in logs. The latter are developer chosen, so nothing will change there. As for the former, users can technically set the algorithm to whatever they want, but doing so exposes their SC to possible theft, so there is basically no reason to do it. Probably >99% of algorithms are "ed25519", so again, no change.
I also decided to add length validation in NewSpecifier. While this is a little annoying, there's no question that silently truncating to 16 bytes has the potential to cause bugs. For example, because of this change, I discovered that "RelayTransactionSet" is actually sent over the wire as "RelayTransaction"! If we had added an RPC for sending a single transaction and called it "RelayTransaction", those IDs would have collided.
Specifiers were always intended to be human-readable IDs. This codifies that by escaping non-alphanumeric specifiers during marshaling. Alphanumeric specifiers are marshaled exactly the same as before.
Non-alphanumeric specifiers are fairly rare. The most common offending character is
" ", which shows up in v1 specifiers like"siacoin output". Also, an early version of the RHP used raw integers in some of its RPC IDs (e.g."RPCDownload\x02"), but those RPCs have been obsolete for many years at this point.Specifiers are primarily seen in two places:
UnlockKeyalgorithms in transaction inputs, and RPC IDs in logs. The latter are developer chosen, so nothing will change there. As for the former, users can technically set the algorithm to whatever they want, but doing so exposes their SC to possible theft, so there is basically no reason to do it. Probably >99% of algorithms are"ed25519", so again, no change.I also decided to add length validation in
NewSpecifier. While this is a little annoying, there's no question that silently truncating to 16 bytes has the potential to cause bugs. For example, because of this change, I discovered that"RelayTransactionSet"is actually sent over the wire as"RelayTransaction"! If we had added an RPC for sending a single transaction and called it"RelayTransaction", those IDs would have collided.