Looking for feedback on a new blockchain address format

[Francesco Ferraro]

Looking for feedback on my blockchain address format

Hello everyone,

I've been building a blockchain project called Ferraro from scratch in Python (not a fork of Bitcoin).

I'm currently experimenting with a different address format.

Instead of a long hexadecimal string, I'm using something closer to an account number:

{
  "address": "F369-5538-4066-7499-9028-0027"
}

This is the current Genesis block:

{
  "block": 0,
  "difficulty": 5,
  "timestamp": 1778196203,
  "transactions": [
    {
      "version": 1,
      "inputs": [],
      "outputs": [
        {
          "address": "F369-5538-4066-7499-9028-0027",
          "amount": 2050000000,
          "currency": "Ferraro"
        }
      ],
      "message": "BLOCK REWARD"
    }
  ]
}

The motivation is simple:

- Easier for humans to read.
- Easier to verify visually.
- Feels closer to an account number than a random hash.

I'm looking for technical opinions:

1. Is this address format a good idea?
2. Would you store the separators ("-") directly in the blockchain, or only use them for display?
3. Do you think this improves usability, or is there a better approach?

I'd really appreciate constructive feedback.

[ercewubam]

Let's see: https://github.com/bitcoin/bitcoin/blob/master/src/base58.h

Code:

/**
 * Why base-58 instead of standard base-64 encoding?
 * - Don't want 0OIl characters that look the same in some fonts and
 *      could be used to create visually identical looking data.
 * - A string with non-alphanumeric characters is not as easily accepted as input.
 * - E-mail usually won't line-break if there's no punctuation to break at.
 * - Double-clicking selects the whole string as one word if it's all alphanumeric.
 */

Your model with dashes explicitly prevents the feature of selecting the whole address with a double click. Currently, we use bech32m for Taproot, which works quite nicely, and you can just introduce it from the start, with some prefix, matching your coin name: https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki

F369-5538-4066-7499-9028-0027

If this is the real address, then do you want to use 96-bit addresses? If so, then after around 2^48 operations, you could have collisions.

Would you store the separators ("-") directly in the blockchain, or only use them for display?

If you store it as an ASCII string, then you are doing it wrong. But anyway: if your chain would be two times bigger than needed, then it is your problem. And also, are these addresses identical, or not?

Code:

F369-5538-4066-7499-9028-0027
f369-5538-4066-7499-9028-0027

Because some users could use A-F, and others could use a-f. If you store it in ASCII, then they would be different, but cryptographically, they could be identical, when parsed to the hex data.

[Francesco Ferraro]

Let's see: https://github.com/bitcoin/bitcoin/blob/master/src/base58.h

Code:

/**
 * Why base-58 instead of standard base-64 encoding?
 * - Don't want 0OIl characters that look the same in some fonts and
 *      could be used to create visually identical looking data.
 * - A string with non-alphanumeric characters is not as easily accepted as input.
 * - E-mail usually won't line-break if there's no punctuation to break at.
 * - Double-clicking selects the whole string as one word if it's all alphanumeric.
 */

Your model with dashes explicitly prevents the feature of selecting the whole address with a double click. Currently, we use bech32m for Taproot, which works quite nicely, and you can just introduce it from the start, with some prefix, matching your coin name: https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki

F369-5538-4066-7499-9028-0027

If this is the real address, then do you want to use 96-bit addresses? If so, then after around 2^48 operations, you could have collisions.

Would you store the separators ("-") directly in the blockchain, or only use them for display?

If you store it as an ASCII string, then you are doing it wrong. But anyway: if your chain would be two times bigger than needed, then it is your problem. And also, are these addresses identical, or not?

Code:

F369-5538-4066-7499-9028-0027
f369-5538-4066-7499-9028-0027

Because some users could use A-F, and others could use a-f. If you store it in ASCII, then they would be different, but cryptographically, they could be identical, when parsed to the hex data.

Thank you for your explanation and for sharing those references.
Ferraro is still an experimental project, so I'm trying different ideas while learning.
I didn't choose a numeric format because I believe it's better than Base58. One of my reasons was simply to reduce visual confusion between characters such as 1 and l, or 0 and O, especially for users who manually read or type addresses on mobile devices.
I understand that every address format has advantages and disadvantages, and I'm still evaluating this design based on community feedback. Your comments are very helpful, so thank you for taking the time to explain them.