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.

[ABCbits]

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

Do not store the separator, usually you want your TX size to be as small as possible to reduce burden of node and allow more TX on a block.

3. Do you think this improves usability, or is there a better approach?

I don't claim it's better approach, but have you checked SWIFT (A-Z) or IBAN (0-9 and A-Z) code format? SWIFT approach is straightforward, while IBAN mitigate typo between letter O and number 0 by mod 97 and other check.

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.

Could be less than 96-bit, if the address also contain checksum.

[Francesco Ferraro]

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

Do not store the separator, usually you want your TX size to be as small as possible to reduce burden of node and allow more TX on a block.

3. Do you think this improves usability, or is there a better approach?

I don't claim it's better approach, but have you checked SWIFT (A-Z) or IBAN (0-9 and A-Z) code format? SWIFT approach is straightforward, while IBAN mitigate typo between letter O and number 0 by mod 97 and other check.

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.

Could be less than 96-bit, if the address also contain checksum.

Thank you again for your suggestions.

I really appreciate the feedback about not storing separators in the blockchain and about using a checksum.

After reading the comments in this thread, I've decided to update my implementation before continuing.

My current plan is:

- Store the address internally without separators.
- Use separators only for display in the wallet/UI.
- Increase the address length.
- Experiment with adding a checksum to reduce typing errors.

Once I've finished these changes, I'll mine a new genesis block and share the updated block JSON here.

I'd really appreciate it if you could review it and let me know whether the structure looks reasonable before I continue with transaction validation, mining, and networking.

Thank you for taking the time to help. I'm learning a lot from this discussion.

[Francesco Ferraro]

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

Do not store the separator, usually you want your TX size to be as small as possible to reduce burden of node and allow more TX on a block.

3. Do you think this improves usability, or is there a better approach?

I don't claim it's better approach, but have you checked SWIFT (A-Z) or IBAN (0-9 and A-Z) code format? SWIFT approach is straightforward, while IBAN mitigate typo between letter O and number 0 by mod 97 and other check.

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.

Could be less than 96-bit, if the address also contain checksum.

Thank you again for your suggestions.

I really appreciate the feedback about not storing separators in the blockchain and about using a checksum.

After reading the comments in this thread, I've decided to update my implementation before continuing.

My current plan is:

- Store the address internally without separators.
- Use separators only for display in the wallet/UI.
- Increase the address length.
- Experiment with adding a checksum to reduce typing errors.

Once I've finished these changes, I'll mine a new genesis block and share the updated block JSON here.

I'd really appreciate it if you could review it and let me know whether the structure looks reasonable before I continue with transaction validation, mining, and networking.

Thank you for taking the time to help. I'm learning a lot from this discussion.