That number, n, and the address would be consensus derived, meaning it can change if a better chain comes in. Imagine giving someone address 1000000, and 10 minutes later it belongs to someone else..
This is why addresses embed the hash of the public key. You need to see a collision in RIPEMD160(SHA256()) to collide an address.
Topic: A small optimization (Read 667 times)
Describe how you would attribute the "nth address" correctly in a distributed network and/or block fork.
I'm assuming your basis would be something along the lines of the "mth" output index in the "nth" transaction would contain the nth address. If only transaction ordering could be reasoned with
As a side note, is 2^48 number of transaction output indexes sufficient for all the addresses in time ever?
What about script hashes?
Basically you're suggesting that you can compress the public address into something smaller, which at best case "might" reduce any scripts that contain 20 bytes hashes of public keys (P2PK) into 4-6 bytes, saving at most 16 bytes. Not even enough to fit another transaction in beside it. So less than doubling the transaction count in a single block (best case).
You're better off doubling the block size capacity (to 2mb) and you already have a better solution.
I'm assuming your basis would be something along the lines of the "mth" output index in the "nth" transaction would contain the nth address. If only transaction ordering could be reasoned with
As a side note, is 2^48 number of transaction output indexes sufficient for all the addresses in time ever?
What about script hashes?
Basically you're suggesting that you can compress the public address into something smaller, which at best case "might" reduce any scripts that contain 20 bytes hashes of public keys (P2PK) into 4-6 bytes, saving at most 16 bytes. Not even enough to fit another transaction in beside it. So less than doubling the transaction count in a single block (best case).
You're better off doubling the block size capacity (to 2mb) and you already have a better solution.
I don't know of an easy way to check, but addresses certainly are reused, even though doing so is not the best practice. Does anyone know what percentage of addresses in (say) recent blocks have already been seen once before on the blockchain?
Since you really shouldn't be re-using addresses anyhow, this idea doesn't seem very useful.
What if, for the special case of an address already seen on the blockchain, it could be referenced by "The nth address on the blockchain" rather than the full address? N could be a 32 (40? 48?) bit number. Is this essentially what "Segregated Witness" does?
Jump to: