Table with used addresses = 4 bytes in send

Not sure if this is being considered / has been discussed / makes sense,
but here’s the idea:

What if every address ever used in Counterparty is saved to a table?
The first address gets index 1, the second index 2 and so on.

If an address is used several times, it will not be saved more than once in the table. It keeps its original index forever.

When creating new transactions it can be optional either to include a full address OR an address index.

If the index takes up 4 bytes, there will be space for (2^8)^4 = 4,294,967,296 addresses.

To date there has been made 850,000 counterparty transactions, and I guess this would imply a few hundred thousand addresses in the index at this point.

FYI… there are just over 91K addresses that have been used in CP.

Each CP send currently stores the source and destination address in the ‘sends’ table… which can/does waste a bunch of space.

For I do what you have suggested outside of the CP system… I have given each unique address an index, and just reference each address in the DB via the index… saves space and avoids having to store any address more than once… but it does make everything dependent on the Addresses table/index.

Just some random thoughts :slight_smile:

Interesting idea.

We’d need a deterministic way of assigning an index to each address. That is possible but certainly adds complexity.

This would have the side effect of making simple send transactions depend on the entire previous history of counterparty transactions. Right now I can parse a send transaction and get all of the information about that send. But if an address index is used, then I would need to parse the entire blockchain to decode a simple send.

1 Like

Thanks for quick replies.

I’ll add the economics of it.

Encoding a full address takes 21 bytes, then using an index instead would save 17 bytes.

Assuming the tx fee is 150 satoshi/byte,
this saves 150 * 17 = 2550 satoshi = 0.00002550 BTC.

At $1000 per BTC, this is 2.55 cents saved.

Of course, as you point out this must be weighed against development time, added complexity, table storage, cpu cycles and necessity of parsing the entire blockchain to decode a send.