Address lookup/name resolution

[tgerring]

Are there any plans to implement a name resolution/lookup service?

I'm making http://paythru.to to be a sort of "internet directory" of bitcoin by connecting twitter/email/websites/sms/facebook/etc together into a single RESTful interface. So, to be able to connect to it from MultiBit "send" tab would be amazing. Obviously, there should be some sort of user-configurable endpoint in the application preferences so they can use whatever service they prefer, but I wanted to get an idea of what it would take to get a feature like this added, since there are other name lookup services in the works and the MBHD is under works.

[1715367928]

1715367928

[1715367928]

1715367928

[jim618]

Hi tgerring,

I just had a look at your site - looks like a useful service to introduce people to bitcoin.

Generally MultiBit is a pretty vanilla code base (to keep it simple and agnostic as possible).
I think pretty much everything (except the XChange integration) has been driven by a BIP or consensus on the bitcoinj mailing list.

(XChange was a bit different as there just wasn't any exchange data library when it was created. No BIPs or anything.)

The payment protocol is a good example of this.

Using a single address for an identity does leak a lot of privacy data. Personally I think people are going to move away from single addresses tied to an identity to something like:

Person A wants to provide a way for Person B to pay them on a regular basis. Person A provides Person B with an extended public key from their HD wallet. Person B imports it into their wallet, labelled "pay Person A with this".

Then each payment Person B makes to Person A is a completely new address and is only used once. (The next payment will use the next address in the generated list of addresses). Only Person A and B know that there is a "payment link" between themselves. Every time Person A receives a payment generated from that extended public key they know it came from Person B. To anyone else parsing the blockchain there is little interconnection (other than the same transaction outputs might be used I suppose).

Also - and please don't take this the wrong way, your service (and others like coinapult) - must _hold_ the bitcoin and hence introduce counterparty risk. I am thinking that if you can refund the bitcoin you must control the private keys. This is a different sort of transaction to one where Person X sends bitcoin to Person Y directly on the Bitcoin network where there is no such risk.

[tgerring]

Person A provides Person B with an extended public key from their HD wallet.

How? Whether the key is a single address or some deterministic extended key, this knowledge transfer currently involves a very user-unfriendly copy & paste dance--and forget it if you're away from your wallet. Having that information available for instant lookup would be a boon to user experience.

This is where basic lookup functionality being added to wallets could prove useful. It would be trivial to build a Namecoin Identity REST wrapper. Project Quixote is also attacking the problem with BitShares. Last I looked, Electrum was building in rudimentary support for name resolution via REST lookup. And who knows what Hive is up to.

Are you saying that you don't see a need for name resolution in Bitcoin wallets?

[jim618]

The great thing about Bitcoin is that there is no single 'right' way to do anything.

One of the things where MultiBit is weak is that it reuses addresses. This is not good at all for privacy.
I'm looking forward to HD wallets to help fix this and then addresses will become more 'disposable'.

It is the usual balance between security/privacy and convenience.

[Mike Hearn]

I'd like to see integration with social networks at some point. A service like paythru.to can be a part of that.

From what I can tell you only act as a bitbank for people who didn't sign up with your directory yet. One they do, the payments are direct and not via you. That seems like a reasonable tradeoff.

What I'd really like to see, once the payment protocol is further along, is hosting sites that will vend payment requests on your behalf. The wallet app would then notice that the payment requests it previously uploaded are almost "used up" and upload a fresh batch in the background. QRcodes and the like can then look like:

bitcoin:1AbCd.....?r=paythru.to/r/a1bZ3

(or whatever), but it's still P2P - paythru.to just provides a convenient rendezvous point that's always online and easy to express as a URL.

Once we have such rendezvous points for the payment protocol, linking with social networks is an obvious next step. The payment protocol could get social extensions so wallets can show a name+photo instead of nothing, when scanning a QRcode. And to do discovery, you can use the photo watermarking trick I described a few months ago - do a search on your favourite social networks, when you find that person, a  paythru.to/r/a1bZ3 type URL can be extracted from the photo and queried to get a payment request message.

In these schemes, paythru.to is not so much a directory (social networks are already directories of people) but rather provides a piece of glue that's missing today. Such sites could eventually use micropayments to bill for their services.

[tgerring]

The great thing about Bitcoin is that there is no single 'right' way to do anything.

One of the things where MultiBit is weak is that it reuses addresses. This is not good at all for privacy.
I'm looking forward to HD wallets to help fix this and then addresses will become more 'disposable'.

It is the usual balance between security/privacy and convenience.

I understand what you're saying and agree with you, but I don't see how HD wallets addresses the problem of passing around long random strings of addresses/keys.

[tgerring]

From what I can tell you only act as a bitbank for people who didn't sign up with your directory yet. One they do, the payments are direct and not via you. That seems like a reasonable tradeoff.

Yes, correct; once their own address is published, my service is completely outside the loop. And although it's "not recommended", the funds are returned to inputs if not claimed for X time. Basically, I don't want your money sitting on my server.

What I'd really like to see, once the payment protocol is further along, is hosting sites that will vend payment requests on your behalf. The wallet app would then notice that the payment requests it previously uploaded are almost "used up" and upload a fresh batch in the background. QRcodes and the like can then look like:

bitcoin:1AbCd.....?r=paythru.to/r/a1bZ3

I'm still trying to wrap my head around the coming changes in QT 0.9 including BIP32. Do you happen to have a link that goes into this specific detail you mentioned a bit more?

In these schemes, paythru.to is not so much a directory (social networks are already directories of people) but rather provides a piece of glue that's missing today.

Well, I'm not aware of any other "universal" internet directory But really, I'm trying to make it trivial to send bitcoins to an existing network/protocol/account, even if they don't have a Bitcoin wallet yet.

As it stands, it's near-impossible to split a bill and pay your share in bitcoins to an acquaintance in part due to the difficulty of discovering & sharing their payment address.

[jim618]

Mike wrote a good FAQ on the payment protocol here:

https://bitcointalk.org/index.php?topic=300809.0


It is written from the perspective of "Bitcoin store issues a payment request to a user, who then pays with a Bitcoin wallet".
That will probably be the first use case that takes off but the payment protocol is more general than that.

I think Mike's suggesting that the Bitcoin wallet creates a load of payment requests and 'bulk' uploads them to your service (I guess you would take payment at this point. Say the user has to pay a milli BTC to upload 100 payment requests).

Then when someone wants the payment details for [insert method of lookup for person here] they get returned a single usage payment request.

It would be a little similar to the posters you get where the bottom row is a whole load of telephone numbers where you just rip off one if you are interested in the service. In this case each chit has individual contact details (to improve privacy).
Once all the chits are ripped off then the user uploads another bunch.

[Mike Hearn]

Exactly.

You can also vend your own payment requests for when the recipient didn't already set things up. The payment protocol has a refund feature so you don't have to take a leap of faith about the inputs anymore.

[tgerring]

I'm still not seeing the case of how this helps me get a payable address to you if we're at lunch and splitting the tab.

If all I know is your name & phone number/email, how do Payment Requests help?

[jim618]

Sometime earlier, Alice uploaded a whole load of payment requests to your website:

Pay Alice (#1)
Pay Alice (#2)
Pay Alice (#3)
Pay Alice (#4)

(all with different addresses to pay to, but Alice's wallet keeps track of those automatically)


Perhaps on your phone, you lookup Alice by name. They'll be several so perhaps you select by photo
You then download the payment request 'Pay Alice (#1)'. It has her payment address in and because your phone understands the Payment Request BIPs it knows what to do with it. This payment address is then 'used up' - your website won't show it again.

Your phone would show a payment screen with the address and you pay it.

[tgerring]

Perhaps on your phone, you lookup Alice by name. They'll be several so perhaps you select by photo
You then download the payment request 'Pay Alice (#1)'.

Again, how? I have to go to a separate website/service? We're saying the wallet should not facilitate looking up users/getting payment requests?

If you wouldn't mind expanding on your previous post, I'd like to know how you see the workflow for "lookup Alice by name" and "download the payment request" when at lunch with a group of people.

[Mike Hearn]

I think you are over-focused on the lunch case. That is likely better solved using mobile wallets with Bluetooth/WiFi Direct that talk to each other and co-ordinate making the payment. I don't see any need for a third party service there.

For the other cases, looking up a user can be done using any kind of social network API. There are libraries for Google+ and Facebook that let you look people up. A link to a payment request can then be steganographically embedded into the photo, or put into some field of the user profile.

[tgerring]

A link to a payment request can then be steganographically embedded into the photo, or put into some field of the user profile.

Even if it Bitcoin Payment Requests existed as a profile field (hello, distant future!), what software or process would make it possible to get payment requests into your wallet without copy/paste?

It sounds like the answer from this thread is only "not the wallet".

[Mike Hearn]

Copy/paste? They aren't intended to be exposed directly to users. Like I said, you'd use bluetooth or wifi+bonjour/etc to help the phones rendezvous and slice the bill.

[tgerring]

Copy/paste? They aren't intended to be exposed directly to users. Like I said, you'd use bluetooth or wifi+bonjour/etc to help the phones rendezvous and slice the bill.

I'm ignoring the "lunch" situation since you feel that it's not the right use case.

This question:

Even if it Bitcoin Payment Requests existed as a profile field, what software or process would make it possible to get payment requests into your wallet without copy/paste?

Is basically the same as this:

Perhaps on your phone, you lookup Alice by name. They'll be several so perhaps you select by photo
You then download the payment request 'Pay Alice (#1)'.

Again, how? I have to go to a separate website/service? We're saying the wallet should not facilitate looking up users/getting payment requests?

Maybe I'm just dense, but I'm not seeing a clear answer in this thread. My suggested solution is that the wallet software should support lookup via a generic REST interface, specifically so that third-party services can flourish.

[Mike Hearn]

I think we're all agreeing without realising it Yes, behind the scenes it'd contact some third party service and download a payment request.