Sorry to dig up a bit of a dusty thread, I found this one after I was thinking about vanity addresses and where else that could lead and I had a thought..
I remember reading that you can send bitcoins directly to an IP address, without prior knowledge of the recipients BTC addresses. The send to IP TX requests a fresh BTC address from the receiving client and then sends coins to that address.
I can't remember if this is where I actually read this the first time, but I found it again in one of Satoshi's own posts here
https://bitcointalk.org/index.php?topic=8.0Since this is was back in the days of version 0.2 I am uncertain if it still applies to the Satoshi client today, else this idea is already dead. I don't know how you can send to IP addresses from the Satoshi client, and have never heard of people using this so if anyone knows any more information that would be appriciated. I'm also no network engineer nor programmer, so I have no idea if there are any serious technical flaws with this idea. If I'm way off here then I'd be interested in a fairly simplified explanation of why it would not work the way I see it.
Say Amazon.com decides to start accepting BTC, they could either setup themselves, or have someone(payment processor?) host for them a server with a dedicated IP running the company's receiving wallet. Have the subdomain btc.amazon.com or paybtc.amazon.com or bitcoin.amazom.com resolve to the applicable IP address for their BTC client server.
Assuming a merchant is savvy enough and chose to operate their own wallet server along with their website, the experience would be something like this. A customer loads a shopping cart, selects pay with bitcoin. To checkout they are given their amount due and a click able link to the relevant vanity address of btc.amazon.com instead of displayed a BTC address. The merchant system monitors the wallet or is notified when payment of the correct amount is received. Since specific receiving addresses aren't available before the transaction to easily associate payments with invoices, the merchant system should be aware of open/pending transactions at the time, and if the amount payable is the same as existing transactions then to increment or discount the amount by a satoshi or two so that the payments are distinguishable.
Client side; If it is possible to have a link which inputs a BTC address into existing client software, then I would think it would not be too difficult to update them to also support direct linking to merchant payment URLs, resolve and pay to the merchants IP. In the same way, I would think web based or 3rd party provided wallet systems would be able and happy to add support for paying to URL/IP.
Finally in the instance of merchants not wanting to deal with clients and wallets, and those who don't want coins at all but instant conversions to fiat things would be a little more complicated. This is where the payment processors would need some ingenuity. What the system would boil down to is that for every merchant, they will require a unique IP with port 8333 forwarded and running that merchants own incoming wallet. You could use a systems with multiple VM's running, one for each merchant, but scaling would be horrible. I am pretty much stuck here. If there was a way to have a single custom client which could manage many wallets at the same time, and somehow could listen on just as many IP addresses at the same time for incoming transactions then this maybe could be created?
Phinn you seem to have a lot of good ideas from what I've read so I thought maybe you'd appriciate this one too..
I've thought about address vanity often. Nearly every non technical person I have introduced to Bitcoin has found the BTC addresses awkward and confusing, so I see it as a bit of a barrier to increased adoption and something we should continue to think about and work on. I'd love to hear peoples comments on this.
- Digigami
