RFC: Bech32 Address Format

[Wollac]

Rendered Version

Example Go implementation in wollac/iota-crypto-demo:

• Bech32 encoding: pkg/bech32
• Example: examples/bech32

[cvarley100]

An HRP of iota would likely be preferable from a UX point of view.

[Wollac]

@cvarley100 the issue is that Bech32 addresses should not be longer than 90 chars. Legacy W-OTS addresses require 80 chars (49 bytes). This plus separator (1 char) plus checksum (6 chars) only leaves up to 3 chars for the HRP.

Instead of violating this restriction of the Bech32 specification (and thus considerably weakening the error detection/correction), there are also some tricks to compress the W-OTS addresses down to 48 bytes, which would allow up to 4 char HRP. But this would require additional description, specs and also probably implementation of this mechanism.

Unless there are some strong UX/PR reasons to go for iota it would be easier to settle with a 3-char HRP like iot.

[cvarley100]

@Wollac Why do we need a separator?

Edit: Answering my own question:

Why include a separator in addresses? That way the human-readable part is unambiguously separated from the data part, avoiding potential collisions with other human-readable parts that share a prefix. It also allows us to avoid having character-set restrictions on the human-readable part. The separator is 1 because using a non-alphanumeric character would complicate copy-pasting of addresses (with no double-click selection in several applications). Therefore an alphanumeric character outside the normal character set was chosen.

[Wollac]

That is just how the Bech32 standard is defined.
They even give a motivation for this here: https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#cite_note-3

[jakubcech]

All for the 3 char iot HRP

[mrbianchi]

• Is good for UX having equal HRP for WOTS and ED25519? ( I know WOTS is larger )
• And will be good for UX changing the actual legacy address format for a new one? ( We can read some user expierences from others projects that did it, like BCH )

I like iota as HRP 😅

[Wollac]

Is good for UX having equal HRP for WOTS and ED25519?

Traditionally, there is only one HRP per coin. This is exactly how other cryptos are handling it and I believe that this is also the intention behind the Bech32 spec:

• BIP-173: P2WPKH and P2WSH use the same HRP (they only differ in length); different witness versions are only denoted by the first byte after the separator.
• SLIP-173: You can only register one HRP per coin and Mainnet / Testnet.

On compromise could be to encode the address type in 5 bits instead of 8 bits (as described in the current version). This would be a bit closer to how BIP-173 encodes the witness version and it would result into having the first character after the separator exactly denote the address type, i.e. iot1q would denote W-OTS and iot1p would denote Ed25519 etc...
However, encoding the version in 5 bits seems a bit arbitrary and would also introduce the complexity of the implementation a bit as we are then mixing base32 with base256. As the completely different address length already provide a very strong visual indicator, I am not sure this would be worth it.

And will be good for UX changing the actual legacy address format for a new one?

The address format described above is just a different encoding for the addresses. No information is lost during conversation. In theory, the wallet could still stick with the legacy format or convert it internally.
That being said, the legacy tryte-based format is not very elegant as it does not offer any version / type, uses a more ambiguous charset and uses a much much weaker checksum not providing any guarantees and easier malleability. Especially since the Bech32 address format has support for different types it would have been strange to not also define it for W-OTS.

[cvarley100]

@Wollac I really think we should go with iota. We have a four letter name, we should take advantage of that. It is only the legacy WOTS addresses that would be over 90 chars.

I propose instead that we use a different identifier for wots, to differentiate it, and allow us to use iota for ed25.

[Wollac]

I don't think this is an option. Bech32 and SLIP-0173 are standards that say that addresses must be at most 90 characters and that they have one human-readable denominator per coin. We should not break those requirements.

@cvarley100 you have mentioned two aspects in your comment:

• If we really want to make the different address types more distinguishable (in case the length difference of 61 vs 90 is not obvious enough) we should modify the "version byte" to make it more readable; e.g. Ed25519 as iot1a and WOTS as iot1b. However
• If we really want to the denominator to be 4-char iota, we have exactly two options:
  • No longer support WOTS in the protocol.
  • Store the WOTS address as at most 48 bytes. This is possible, by either truncating the address hash - this will theoretically lead to more address collisions! Or by encode the address as 48 bytes by applying the Kerl trits-bytes encoding. Currently, this step is only part of the Kerl hash function and implementing this encoding would require additional afford ad well as validation etc. Does having a slightly nicer hrp really justify these steps?

[cvarley100]

@Wollac Why do legacy addresses need to subscribe to bech32 encoding?

[Wollac]

Of course they don't need to be, they can be in Morse code or any other encoding. However, it is exactly the point of this RFC to have one common encoding for all current and future address types and versions.
If it is really that crucial to exactly have iota, then we should either remove WOTS from the protocol completely or we need to bite the bullet and implement the more complicated encoding.

[jakubcech]

I'm not a fan of going to great lengths for the iota HRP. Especially since neither of the complications to achieve 48 byte address are very nice, unless the collision rate would be absolutely negligible. I see iota being better for our UX for sure, but I don't see it as that big a benefit.

At the end of the day, we're building a protocol for the IoT. 🤷

[charlesthompson3]

Here are a pair of very minor edits to grammar; please let me know if you have any questions about them!

-Charles

[karimodm]

If WOTS does not need to be encoded; conversations with wallet people, various engineers and bizdev concluded that the most agreed is 4-char prefix: iota / atoi.
They are both really recognizable ad very different from each other.

[Wollac]

The first and only supported address type (Ed25519) uses 1 instead of 0. This tries to stay consistent with the address type in other RFCs, but should be unified once those types have been finalized.

[thibault-martinez]

Should we just go forward, remove WOTS from the other RFCs and use 0 ?

[Wollac]

@cvarley100 you can make the final call about the HRPs and we will adapt those!

[Wollac]

OK iota and atoi it is!