Can a receiving address be the hash of an IP address?

[keiha]

Can that be done for the sending address as well?

[1715539313]

1715539313

[1715539313]

1715539313

[1715539313]

1715539313

[1715539313]

1715539313

[1715539313]

1715539313

[darosior]

Can that be done for the sending address as well?

You could make a payment to a hash of an ip, but you would not have the corresponding private key in this case. An address is derived (hashed) from a public key, itself derived from the private key : you have to first generate the private key in order to generate an address.

[khaled0111]

The only way I can think of is to use the hash of IP as the private key then derive the public address from it.
You should not do it for security reasons, obviously.

[keiha]

Could you publish the private key (after transferring BTC out of that address)?

OP_RETURN could be used for the domain name, and create a DNS on the blockchain.

[pooya87]

are you still trying to duplicate NameCoin on bitcoin?

OP_RETURN could be used for the domain name, and create a DNS on the blockchain.

bitcoin is a currency and a payment system, it should not be used for things that are not related to that. in fact OP_RETURN should not have even been added to bitcoin in first place.
but yes you can do that. here is a cool project running a website without host, DNS,... and purely decentralized using OP_RETURN data on bitcoin network https://github.com/elendirx/web2web

[CryptoReggae]

I remember reading a discussion by Satoshi explaining how to use IP as a sending recipient.
Good times now gone, now I honestly don't know if what you ask is possible

[bob123]

This is not possible to quite a lot of reasons.
I will list a few without a in-depth explanation because i think it really is not required here:

• IPs are given out dynamically
  You might have a specific IP today, a different tomorrow and a completely new one the day after.
  
  
• 'Adresses' do not exist on a technical level. An address is just a readable format for humans.
  On a technical level, transactions have public keys as 'receiver / sender'.
  
  
• 'Adresses' or public keys, are generated by doing mathematical operations on the private key.
  You need the private key (very big random number) FIRST, then you can create a public key out of it (and therefore also derive an 'address').
  
  
• Most internet user are sitting behind a NAT from their ISP.
  This is due to the fact that there are way too much internet devices than IPv4 addresses (there are 4,294,967,296; from which a lot of them can't be given out because of being reserved etc..)
  While you might see your 'public IP', you can't be reached from outside at this IP. All of your packets are getting routed through the NAT which changes your IP to the 'real' IP (the one from the ISP).
  Answers are getting translated and getting routed into the ISP's subnet to your 'internal public IP'.
  
  
• The time of IPv4 addresses is coming to an end (see previous point).
  There is a (very) slow transition onto IPv6 going on (which will have an IP space of 3.4 * 10³⁸ IPs.
  So the whole IP format is going to change anyway.
  
  

And.. most importantly.. it is not necessary at all. You would gain 0 benefit from it.
In fact, it wouldn't even make sense.