Topic: Bitcoin Address "IPs to Domains"? (Read 1457 times)
Like VPN Coin do?
Check out OpenAlias. Designed by the Monero Developers. It works for Bitcoin too. All you need to do is put a TXT record in a domain of your choice and you can send BTC or XMR there.
for example = saddam.moneroaddress.org is my OpenAlias address for Monero.
for example = saddam.moneroaddress.org is my OpenAlias address for Monero.
as phillipsjk said. it has been done.
you would have to use, and thus trust, a third party to be the intermediary thus most probably wouldn't use it.
you would have to use, and thus trust, a third party to be the intermediary thus most probably wouldn't use it.
I would if the third party was extremely trustworthy.
Otherwise bitcoinwallet.com could work since you can have [NAME].bitcoinwallet.com as your wallet!
as phillipsjk said. it has been done.
you would have to use, and thus trust, a third party to be the intermediary thus most probably wouldn't use it.
you would have to use, and thus trust, a third party to be the intermediary thus most probably wouldn't use it.
Memorable addresses have been tried and abandoned.
One Centralized solution is first bits.
However, you have to trust that website not to generate colliding addresses in order to prompt people to send funds to the wrong address. A more decentralized solution is Vanitygen, but you still have to be wary of potential collisions.
Because the Block-chain is public, it is best to avoid address re-use anyway. Best practice is to use a new address for each transaction. If your address is "well known", it is trivial to track your spends: even more so if your payments go to other "well known" addresses such as the laminated card used by your local coffee shop.
Coinjoin is meant to mitigate this (mostly a work in progress).
One Centralized solution is first bits.
However, you have to trust that website not to generate colliding addresses in order to prompt people to send funds to the wrong address. A more decentralized solution is Vanitygen, but you still have to be wary of potential collisions.
Because the Block-chain is public, it is best to avoid address re-use anyway. Best practice is to use a new address for each transaction. If your address is "well known", it is trivial to track your spends: even more so if your payments go to other "well known" addresses such as the laminated card used by your local coffee shop.
Coinjoin is meant to mitigate this (mostly a work in progress).
Will take a look, interesting.
Memorable addresses have been tried and abandoned.
One Centralized solution is first bits.
However, you have to trust that website not to generate colliding addresses in order to prompt people to send funds to the wrong address. A more decentralized solution is Vanitygen, but you still have to be wary of potential collisions.
Because the Block-chain is public, it is best to avoid address re-use anyway. Best practice is to use a new address for each transaction. If your address is "well known", it is trivial to track your spends: even more so if your payments go to other "well known" addresses such as the laminated card used by your local coffee shop.
Coinjoin is meant to mitigate this (mostly a work in progress).
One Centralized solution is first bits.
However, you have to trust that website not to generate colliding addresses in order to prompt people to send funds to the wrong address. A more decentralized solution is Vanitygen, but you still have to be wary of potential collisions.
Because the Block-chain is public, it is best to avoid address re-use anyway. Best practice is to use a new address for each transaction. If your address is "well known", it is trivial to track your spends: even more so if your payments go to other "well known" addresses such as the laminated card used by your local coffee shop.
Coinjoin is meant to mitigate this (mostly a work in progress).
This is true. To acquire a name server would introduce centralization issues. I/O coins did a good job on this. You can see the details here:
http://www.docdroid.net/file/view/fl3r/usernames-paper.pdf
They did it in a decentralized manner, though the need for the servers introduces centralization issues again, which in the case of Bitcoin would be a very bad idea. Perhaps later on with the introduction of small contracts one could acquire such a thing. The other progressions are also interesting.
Cheers.
Memorable addresses have been tried and abandoned.
One Centralized solution is first bits.
However, you have to trust that website not to generate colliding addresses in order to prompt people to send funds to the wrong address. A more decentralized solution is Vanitygen, but you still have to be wary of potential collisions.
Because the Block-chain is public, it is best to avoid address re-use anyway. Best practice is to use a new address for each transaction. If your address is "well known", it is trivial to track your spends: even more so if your payments go to other "well known" addresses such as the laminated card used by your local coffee shop.
Coinjoin is meant to mitigate this (mostly a work in progress).
One Centralized solution is first bits.
However, you have to trust that website not to generate colliding addresses in order to prompt people to send funds to the wrong address. A more decentralized solution is Vanitygen, but you still have to be wary of potential collisions.
Because the Block-chain is public, it is best to avoid address re-use anyway. Best practice is to use a new address for each transaction. If your address is "well known", it is trivial to track your spends: even more so if your payments go to other "well known" addresses such as the laminated card used by your local coffee shop.
Coinjoin is meant to mitigate this (mostly a work in progress).
The receiver address is part of the transaction. You can't just put IP-addresses there instead of BTC-addresses.
Actually, the address is not part of the transaction.
Addresses are just a standard way for humans to discuss a more complicated set of instructions.
What exists in the transaction is a set of instructions that say:
"In order for this unspent output to be spent, the spender must provide an ECDSA signature using the secp256k1 curve which can be validated with a public key that hashes to the following value when hashed first with SHA256 and then with RIPEMD160."
The "value" that is then provided is a 48 digit number that is calculated from the information in the bitcoin address and which is stored by computers in binary (resulting in a value that is represented by your computer with one hundred sixty 1's and 0's) and often displayed as 40 Hex Decimal digits.
That is the "standard" bitcoin output script and it is represented by addresses that start with a "1". Specifically in the encoding to base 58, when the first 8 bits (the first byte) of an address are all 0's then those 8 bits are encoded as a single "1". All bitcoin wallets are written to understand that when an address converted from base58 back to binary has a first byte of zero, it means to create the specific set of instructions described above.
There are other "scripts" that encumber the output with other requirements which can be used as well. For example, this is why you can see addresses that start with a '3'. Those addresses have a completely different set of instructions that are part of the transaction, and wallets that accept addresses that start with a '3', know what script they are supposed to use for that indicator.
It is even possible to create a transaction with a script that has no standard address representation at all. Since there is no standard indicator for such a custom script, you wouldn't be able to use a typical wallet to create such a transaction or to spend the output created by such a transaction. You would instead need to create your own software to properly encode the script into the transaction, and your won software to meet the requirements of the script when you want to later spend it.
According to this link, that IP had to run BitcoinD on it, which used to generate address for the sender. That address was associated with the IP. But, as internet traffic can be intercepted and an attacker can overwrite the address against an IP, this method has been abandoned from the protocol.
Exactly. That's why the OP's proposal is not a good one.
Originally Bitcoin was able to send to an IP instead of an address, but it was disabled (for security concerns, I guess)
How is that supposed to be possible?The receiver address is part of the transaction. You can't just put IP-addresses there instead of BTC-addresses.
I don't know the technical details, but there's a wiki entry about it. https://en.bitcoin.it/wiki/IP_Transactions
and yes it is pretty obvious that this was vulnerable to attacks and so had to be discontinued.
Originally Bitcoin was able to send to an IP instead of an address, but it was disabled (for security concerns, I guess)
How is that supposed to be possible?The receiver address is part of the transaction. You can't just put IP-addresses there instead of BTC-addresses.
I don't know the technical details, but there's a wiki entry about it. https://en.bitcoin.it/wiki/IP_Transactions
According to this link, that IP had to run BitcoinD on it, which used to generate address for the sender. That address was associated with the IP. But, as internet traffic can be intercepted and an attacker can overwrite the address against an IP, this method has been abandoned from the protocol.
Any attacker can easily access the ip address fro the network router. So its not good to user IP addresses.
Originally Bitcoin was able to send to an IP instead of an address, but it was disabled (for security concerns, I guess)
How is that supposed to be possible?The receiver address is part of the transaction. You can't just put IP-addresses there instead of BTC-addresses.
I don't know the technical details, but there's a wiki entry about it. https://en.bitcoin.it/wiki/IP_Transactions
According to this link, that IP had to run BitcoinD on it, which used to generate address for the sender. That address was associated with the IP. But, as internet traffic can be intercepted and an attacker can overwrite the address against an IP, this method has been abandoned from the protocol.
Originally Bitcoin was able to send to an IP instead of an address, but it was disabled (for security concerns, I guess)
How is that supposed to be possible?The receiver address is part of the transaction. You can't just put IP-addresses there instead of BTC-addresses.
I don't know the technical details, but there's a wiki entry about it. https://en.bitcoin.it/wiki/IP_Transactions
Originally Bitcoin was able to send to an IP instead of an address, but it was disabled (for security concerns, I guess)
How is that supposed to be possible?The receiver address is part of the transaction. You can't just put IP-addresses there instead of BTC-addresses.
Originally Bitcoin was able to send to an IP instead of an address, but it was disabled (for security concerns, I guess)
in some years these BTC addresses will disappear for sure.
Pretty much anything is possible, it is a question of the ramifications of them. :-)
A couple of links:
https://medium.com/@davidshares/bitcoin-addresses-are-too-long-and-unmemorable-49635b4aed3e
https://bitcointalksearch.org/topic/bitcoin-address-shortener-8227
https://en.bitcoin.it/wiki/Firstbits
A couple of links:
https://medium.com/@davidshares/bitcoin-addresses-are-too-long-and-unmemorable-49635b4aed3e
https://bitcointalksearch.org/topic/bitcoin-address-shortener-8227
https://en.bitcoin.it/wiki/Firstbits
Would this be possible?
To make a bitcoin address a short, memorisable alphanumeric sequence like domains do for IPs.
To make a bitcoin address a short, memorisable alphanumeric sequence like domains do for IPs.
ive heard of address generators that try to make the best memorisable solution, but would be carefull tho.
theres a reason why addresses are the way they are.
cheers
I think is a great idea for a new startup to sell bitdomain for bitcoin adresses or for a future bitcoin core update to use bit domains in the top of the bitcoin address
Jump to: