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)