mackuba
commented
10 years ago Heh, I was going to post my own "wall of text" issue today... so I'll just post it here as a comment instead. [TLDR WARNING]
I feel like all those extensions to the protocol we've been talking about recently somehow fit together into a bigger picture, but it's hard to see that picture if we're only talking about them one at a time. So I wanted to have one place that describes this all together, looks like you had the same idea.
Also, I wanted to say that we should be careful not to rush any solutions without taking the necessary time to think this through. This is all bleeding edge stuff, things that mostly haven't been done in any wallet yet, so we're starting to explore the unknown here. It's even quite possible that we'll choose something, implement it and then later realize it's not going to work and rebuild it again.
There are two major parts I can see here, that roughly map to the "identity" and "payment" parts in the issue title:
- How do we help two people make a permanent connection between their wallets that helps them make transactions between each other (i.e. how do we get them on each other's contact lists)?
- How does this connection actually work, i.e. how do we let them send and receive money from each other once they're connected?
We also need to take into account that:
- we want to preserve or improve users' privacy whenever possible
- BIP32 and constantly changing addresses help with the privacy, but complicate both 1) and 2), because they break the 1-to-1 mapping between a person and a Bitcoin address
- whenever possible, it would be better to design solutions that would/might be compatible with other wallets, instead of locking in everyone to Hive, Microsoft/Apple-style
So, for 1), we have such ideas:
-
9 (local peer discovery) for making the connection in person
-
1 (lookup by phone number / email) for making a connection with people who are on our existing contact lists
-
5 (Hive transport layer) with the connection initiated manually over a different channel ("Hi Bob, please follow this link to accept my invitation") and then completed over the transport layer
- some kind of public profile pages a la onename.io, as discussed today on Slack - that let a person present their identity on the profile page, and then any random person can somehow make a connection with them if they find the profile page
- stuff described above by @javgh
Right now I think a combination of #1 + #5 + #9 would make the most sense; I'm not very enthusiastic about the idea of public profile pages and putting data and addresses on them for everyone to see. Though that could work too, but I think the master public key would have to be kept safe server-side, so that everyone can't see all the addresses that were generated there.
Once we have a connection, we want to send and request/receive money (2). This poses the following problems:
- If we want to keep showing names and faces on the transactions list, we need to identify the person sending the transaction. How do we do that then if the "from" address constantly changes (hi lukejr ;)? The only ways I can think of are:
- have some kind of short identity token that maps to a specific person, and include it in the transaction data, so that any person who has this person on their contact list can recognize the person by this token (note: I don't know if this is actually possible) (edit: nevermind, this is a terrible idea, as this would make your all transactions recognizable as coming from a single wallet, which defeats the whole purpose of BIP32)
- try to use Payment Protocol whenever possible; I was going to write that this implies you have to always request a Payment Request first from the receiver to make a payment, but I think it should be possible to just send Payment messages unannounced whenever you want. However, this probably requires a separate channel through which this would be sent (i.e. #5 Hive transport layer), since unlike merchants, users will not have a permanent and publicly available http URL that you can submit the message to. We'd also need some kind of contact data related extensions to the Payment Protocol, possibly something like what Taylor was thinking about in November.
- How do we communicate to the other person that we want them to send us money?
- we could generate a Payment Request and just send it via email (like in PayPal you create a request to someone and it gets send to their email address - we'd design some nice HTML mail layout that explains what this is about and includes a bitcoin: URL)
- or we could also use #5 for that, and display the request directly in Hive on the other side (downsides: that would be Hive-specific, and would only show up when the receiver is running Hive, while an email would probably be noticed much quicker)
- If I want to send money to a contact without them requesting it first, how do I know what address to send to?
- you could somehow request a new Payment Request first before you make a payment (there was this idea of publishing a number of pre-generated requests somewhere), but that sounds a bit messy and unreliable
- alternatively, we could create a completely separate BIP32 chain of addresses for this specific relationship, and have the people share the master public keys of the chains as a part of the connection making process; that way, each of your contacts would be able to generate a new address for every new transaction sent to you, but the addresses would form completely separate pools, so all our contacts wouldn’t see each other’s transactions. I’m not sure if this isn’t abusing the BIP32 recommended wallet layout a bit, but the BIP describes something of this kind in the section “Recurrent business-to-business transactions”.
- stealth addresses kind of get around the problem, but they also require a separate channel to communicate the nonce to the receiver (again, see #5), and they're sort of a completely separate system, to the point that I think they're not even compatible with BIP32, as the private key is generated from the nonce instead of any of the master private keys...
So that's how I see it. I don't have many answers, mostly more questions, but I guess at least it's good to see them all in one place...
tgerring
I wanted to summarize some ideas we discussed earlier regarding identity and add my thoughts regarding the different options.
Obviously the question of identity comes up quickly when one tries to implement payments between "people", because the question is, how are these people identified and - more importantly - how do they find each other.
Identity systems that are already in wide-spread use are more helpful in this latter respect, as people already know their friends' identities on those systems. Examples for wide-spread identity systems would be:
Facebook and Google allow to leverage their identity systems with "Sign up with Facebook"-type mechanisms. In a discussion with Mike Hearn over in issue https://github.com/hivewallet/discussions/issues/5 I already listed some reasons why I am not in favor of social network integration. Specifically:
But I'm not against opening that discussion again.
Email addresses and phone numbers are kind-of "overloaded" identities. They have a core functionality (e.g. receiving email), but are then often used as identities within other systems. So for example Coinbase uses their users' email addresses as login names, so you can send bitcoins to "an email address", provided that person uses Coinbase and you do the transaction through Coinbase. But of course that's really "some.user@gmail.com @ coinbase.com" which would not necessarily be compatible with another Bitcoin wallet service that also provides an "send to email address" feature.
If one wanted to make "pay to email address" work in general, one would need to upstream that lookup to the actual domain. So that would require some kind of DNS extension, where you can ask the DNS server at gmail.com for a Bitcoin address for some.user@gmail.com . I think there have been many discussion about this on the Bitcoin mailing list, but they often ran into problems with DNS not being secure enough for that, even with DNSSEC, although I might be misremembering that. Regardless, it's probably a very long-term solution, which seems unlikely to happen anytime soon.
KNCWallet ( http://kncwallet.com/ ) is an example for an overloaded phone number, as they essentially use your phone number as an identifier in their system, which means you can find all your friends easily, at least if they use KNCWallet as well (the "Whatsapp approach", see also issue https://github.com/hivewallet/discussions/issues/1 ).
Leveraging email addresses or phone numbers however requires to verify those first (with a "follow this link" email or a code via SMS), to prevent someone who isn't the owner from claiming the address (e.g. signing up as gavinandresen@gmail.com at Coinbase and then asking for donations to that address).
Note, that the payment protocol does not provide a solution for "pay to email address" - even if Wendell likes to claim that from time to time. ;-P The payment protocol only offers an (optional) mechanism to verify, that a payment request, that you already have, was signed by the owner of a specific email address (if that person has gotten a certificate for their email address, which you need to get from someone like StartCom). That still leaves you with the problem of getting the payment request in the first place.
Then there are identity systems which are not used much or not at all so far, like:
PGP keys can also have email addresses attached, but those are not verified. So someone can just upload a key with the email address gavinandresen@gmail.com attached and in fact someone did. So PGP keys are really a separate identity. The nice thing about them is, that there is already some infrastructure, like key servers, that can be used. The downside is, that pretty much nobody has a PGP key, so conversely they also don't know any PGP keys of their friends.
OneName is an interesting project, in that it provides a namespace managed by a blockchain (in this case Namecoin). However, again, no one has OneName accounts, so it's not really helpful in finding your friends. Email addresses can be attached, but so far they are also not verified, if I remember correctly. Another point to keep in mind regarding OneName is, that it costs Namecoins to register the underlying account. This is currently paid for by OneName, but will probably not stay like this forever.
I don't know much about Keyhotee, as I found it difficult to figure out how the systems works exactly from the existing documentation. I think it's sort of Namecoin plus some additional features.
As a kind of combination of the above things there is Keybase ( https://keybase.io/ ). It's an interesting project, which creates a new identity (a Keybase username) with an associated PGP key, but then allows you to publish identity proofs on other services, to enrich that identity. So for example for a keybase user "maria" (the example on their site), you could independently verify, that it belongs to someone who controls maria_h20 on Twitter and the web domain mariah20.com. If you know, for example, that the Twitter handle is legit, then you have also verified the Keybase login. It's in limited beta at the moment. I believe that OneName is also moving into a similar direction, which would be a good step, I think.
One can of course also start one's own identity systems, which many sites do (or do in addition to social network sign-in). So in the case of Hive, that could be a username (or also an email address, but then with a verification step).
Finally, as a subcategory of the above, there can be "no identity" or rather no visible identity. In this case the Hive username still exists, but is just a randomly generated token that is only used internally and never shown to a user (like hiveuser_fjek39wirubxjaksdjghwedfgawqer).
For Hive Android, I am currently planning on going with that last option. The big advantage is, that it requires no sign-up step, as picking a random username can just happen automatically in the background. The disadvantage is, that there is nothing to give to other users. Instead, one can only send "invitiation links", which are a mechanism to hide the ugly random username and communicate it behind the scenes. A wallet, which understands the invitation link, can then receive the actual username and get in touch with the other wallet, to perform payments etc. (see https://github.com/hivewallet/discussions/issues/5 again).
For me the runner-up alternative would probably be Hive usernames, that the user is picking when signing up. This requires no verification step, just a check that the username is not taken yet. Those usernames can then also be given to other users or used in the form of a public page, as proposed with the "Pollen" idea by David & co. The password for that login would be the passphrase.
Those two approaches could also be combined, in that the user might start out with a randomly generated username and then later just upgrades to a hand-picked username/alias.