Bitcoin Forum
August 10, 2022, 10:43:32 PM *
News: Latest Bitcoin Core release: 23.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: A small optimization  (Read 638 times)
teppy
Full Member
***
Offline Offline

Activity: 184
Merit: 101


View Profile
January 15, 2016, 02:05:59 PM
 #1

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?

Dragon's Tale is the longest running Bitcoin enterprise in the world.
1660171412
Hero Member
*
Offline Offline

Posts: 1660171412

View Profile Personal Message (Offline)

Ignore
1660171412
Reply with quote  #2

1660171412
Report to moderator
1660171412
Hero Member
*
Offline Offline

Posts: 1660171412

View Profile Personal Message (Offline)

Ignore
1660171412
Reply with quote  #2

1660171412
Report to moderator
icon
Automate your trading like a pro. Lightning fast execution.
Start trading
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
DannyHamilton
Legendary
*
Offline Offline

Activity: 2870
Merit: 3407



View Profile
January 15, 2016, 02:24:44 PM
 #2

Since you really shouldn't be re-using addresses anyhow, this idea doesn't seem very useful.
teppy
Full Member
***
Offline Offline

Activity: 184
Merit: 101


View Profile
January 15, 2016, 02:30:13 PM
 #3

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?

Dragon's Tale is the longest running Bitcoin enterprise in the world.
aschk
Newbie
*
Offline Offline

Activity: 4
Merit: 0


View Profile
January 15, 2016, 02:38:45 PM
 #4

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 Wink

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.
fbueller
Sr. Member
****
Offline Offline

Activity: 412
Merit: 250


View Profile
January 15, 2016, 04:26:15 PM
 #5

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.

Bitwasp Developer.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!