Looking for feedback on my UTXO model and address format

[Francesco Ferraro]

Hi everyone,

I'm continuing to improve my hobby blockchain project written in Python.

At the moment I'm implementing a Bitcoin-style UTXO model. The node can already return both balance and UTXO information through the API.

Example:

GET /balance/<address>
{
  "balance": 2050000000
}

GET /utxo/<address>
{
  "utxos": [
    {
      "address": "F369-5538-4066-7499-9028-0027",
      "amount": 2050000000,
      "spent": false,
      "txid": "dbd1af28d5894c29ed2231230e1e526d3995585c8b5180b8a94d6a983e05b152",
      "vout": 0
    }
  ]
}

I intentionally keep the structure simple while I learn how Bitcoin's UTXO model works.

I'd like to ask for feedback:

1. Does this UTXO structure look reasonable?
2. Am I missing any important fields?
3. Is there anything you would recommend changing before I continue with transaction validation and mining?

I'm still learning, so any suggestions are appreciated.

Thank you.

[OsaiEmma]

I'd like to ask for feedback:

1. Does this UTXO structure look reasonable?
2. Am I missing any important fields?
3. Is there anything you would recommend changing before I continue with transaction validation and mining?

I'm still learning, so any suggestions are appreciated.

Thank you.

1) Yes it does to me but with a little tweak: I'd recommend you remove this

Code:

 "spent": false,

The reason is that it feels redundant. This is an unspent transaction output (UTXO) meaning it is unspent; spent will never be true, so there is no need for it.

2) Yea, I'd suggest block_height for proper identification.

3) Just the 2 above, I know some other members might have more suggestions.

[nc50lc]

2. Am I missing any important fields?

You haven't explained the example use-case of that API response.

At minimum, you'll only need the TXID, Vout and the amount. The client can already create a transaction using those.
Minimizing the API response's size is a better idea than adding more bloat to it.

Off topic: you might want to reconsider the address format though.
16^24 has quite weaker collision resistance than bitcoin's address and I suppose wont be safe in the near future.

[Francesco Ferraro]

2. Am I missing any important fields?

You haven't explained the example use-case of that API response.

At minimum, you'll only need the TXID, Vout and the amount. The client can already create a transaction using those.
Minimizing the API response's size is a better idea than adding more bloat to it.

Off topic: you might want to reconsider the address format though.
16^24 has quite weaker collision resistance than bitcoin's address and I suppose wont be safe in the near future.

Thank you for the suggestion.

The current API is mainly intended for my wallet application, so I initially included additional information for debugging and testing while I'm still learning.

I'll simplify the UTXO response and only keep the fields that are actually necessary.

Regarding the address format, thank you as well. I'm still experimenting with different ideas, so I'll study collision resistance more carefully before considering it final.

I'd like to ask for feedback:

1. Does this UTXO structure look reasonable?
2. Am I missing any important fields?
3. Is there anything you would recommend changing before I continue with transaction validation and mining?

I'm still learning, so any suggestions are appreciated.

Thank you.

1) Yes it does to me but with a little tweak: I'd recommend you remove this

Code:

 "spent": false,

The reason is that it feels redundant. This is an unspent transaction output (UTXO) meaning it is unspent; spent will never be true, so there is no need for it.

2) Yea, I'd suggest block_height for proper identification.

3) Just the 2 above, I know some other members might have more suggestions.

Thank you for your feedback.

You're right. Keeping "spent": false inside the UTXO response is redundant because an unspent transaction output is already a UTXO by definition.

I'll remove that field and also add the block height as you suggested.

Thank you for taking the time to review it.

[nc50lc]

You haven't explained the example use-case of that API response.

The current API is mainly intended for my wallet application, so I initially included additional information for debugging and testing while I'm still learning.

Though, the address that's already given by the client in the request, to be returned in each UTXO doesn't look useful IMO.

Regarding the address format, thank you as well. I'm still experimenting with different ideas, so I'll study collision resistance more carefully before considering it final.

For starters, there are "approximately" 2^256 private keys if you're following Bitcoin's standard; while your example address is only 2^96.
With that design, there are 1,461,501,637,330,902,918,203,684,832,716,283,019,655,932,542,976 private keys that could derive the same address.
(a little bit less if we discount the outside range private keys)

[Francesco Ferraro]

You haven't explained the example use-case of that API response.

The current API is mainly intended for my wallet application, so I initially included additional information for debugging and testing while I'm still learning.

Though, the address that's already given by the client in the request, to be returned in each UTXO doesn't look useful IMO.

Regarding the address format, thank you as well. I'm still experimenting with different ideas, so I'll study collision resistance more carefully before considering it final.

For starters, there are "approximately" 2^256 private keys if you're following Bitcoin's standard; while your example address is only 2^96.
With that design, there are 1,461,501,637,330,902,918,203,684,832,716,283,019,655,932,542,976 private keys that could derive the same address.
(a little bit less if we discount the outside range private keys)

Thank you very much for the detailed explanation.

You're right. My current address format significantly reduces the address space because I only use numeric characters.

This is still an experimental design, so I'll revisit the address generation before considering it final. My original goal was to make addresses easier to read and transcribe, but I understand that collision resistance is much more important.

I'll update the implementation and publish the revised specification together with the reference code so it can be reviewed again.

I really appreciate your feedback.

[Francesco Ferraro]

# Ferraro Development Log

---

# Genesis Block V2

Status

✅ Genesis Block V2 Successfully Mined

---

## Mining Information

Algorithm : Ferraro CPU Algorithm

Consensus : Proof of Work (CPU)

Difficulty : 5

Nonce : 1206848

Hashrate : ~73 H/s

Platform : Android (Termux)

CPU Buffer : 2 MB

CPU Rounds : 2

---

## CPU Usage

```
800%cpu   0%user   0%nice   0%sys
800%idle  0%iow    0%irq    0%sirq

PID USER         PR  NI VIRT  RES  SHR S %CPU %MEM     TIME+ ARGS
7733 u0_a289      20   0  63M 7.8M 3.0M R 95.6   0.2  37:45.07 python
```

---

## Mining Engine

```python
CPU_BUFFER_SIZE = 2 * 1024 * 1024
CPU_ROUNDS = 2
```

Mining Loop

```python
start = time.time()
last_print = time.time()
hashes = 0

clean = dict(block)
clean.pop("chain", None)
clean.pop("nonce", None)

header = blockchain.serialize(clean).encode()

seed = blockchain.dsha256_bytes(header)

buffer = blockchain.build_cpu_buffer(seed)

while True:

    h = blockchain.cpu_algorithm(
        buffer,
        seed,
        block["nonce"]
    )

    hashes += 1

    if h.startswith("0" * difficulty):

        block["chain"] = h

        break

    block["nonce"] += 1
```

---

## Genesis Block JSON

```json
[
  {
    "block": 0,
    "timestamp": 1778196203,
    "difficulty": 5,
    "merkle_root": "65ff7c35d69a79f173723a370cdf132f358883f5439d2f2595dc77f4e3b38f38",
    "transactions": [
      {
        "version": 1,
        "inputs": [],
        "outputs": [
          {
            "address": "F369077297756330555934711364126937148742295398586755",
            "amount": 2050000000,
            "currency": "Ferraro"
          }
        ],
        "timestamp": 1778196203,
        "Francesco Ferraro": "Why?",
        "message": "Reuters 06/May/2026 Global debt hits record of near $353 trillion",
        "txid": "65ff7c35d69a79f173723a370cdf132f358883f5439d2f2595dc77f4e3b38f38"
      }
    ],
    "previous_chain": "0000000000000000000000000000000000000000000000000000000000000000",
    "nonce": 1206848,
    "chain": "000006f97607ae15640fb107597046ff1e727d283af86396d1b6c08036906231"
  },
  {
    "block": 1,
    "timestamp": 1785176691,
    "difficulty": 5,
    "merkle_root": "bd72b859232a177bba9dd6a61c88f58fc21032181729c84d2ff717f974d64aad",
    "transactions": [
      {
        "version": 1,
        "inputs": [],
        "outputs": [
          {
            "address": "F369077297756330555934711364126937148742295398586755",
            "amount": 2050000000,
            "currency": "Ferraro"
          }
        ],
        "timestamp": 1785176691,
        "message": "BLOCK REWARD",
        "txid": "bd72b859232a177bba9dd6a61c88f58fc21032181729c84d2ff717f974d64aad"
      }
    ],
    "previous_chain": "000006f97607ae15640fb107597046ff1e727d283af86396d1b6c08036906231",
    "nonce": 772963,
    "chain": "000005f4bb32bf6c428378f36237980b43a921e334b5fe2dd054aac6ee92f0c5"
  }
]
```

---

## Notes

Genesis reward is permanently locked.

Genesis exists only as the origin of the blockchain.

Spendable coins begin from Block #1.

---

## Next Development

- CPU Mining Engine
- First Transaction (Block #2)
- UTXO Validation
- Peer-to-Peer Broadcast
- Network Synchronization

One Vote = One CPU.