Thanks Mike.
I definitely took all your comments to heart, but we're looking to road-test
something quickly for the sake of user experience in our own wallet. I wouldn't
mind us contributing to a BIP once we have a better grip on the payment
protocol itself, but (for example) I'm still not sure
The payment protocol doesn't *require* signed certificates, it just gives
the option of using them.
However if you don't have some kind of cryptographic proof of identity,
what stops me putting your name and face into my payment requests and
claiming to be you?
You can prove ownership of a private key by signing a challenger-generated
nonce with the public part and giving the signature back to the challenger
- same as with any asymmetric crypto system.
As I already noted, the payment protocol is designed to solve that problem.
You could design a BIP that
Couple of things I just thought about:
1- Presume server should only sweep with two (or more, see below) revocation
certificates being present
2- Need to insert something in the flow so that Alice can verify that the
uploaded key is actually Bob's (and perhaps vise-versa, given an extremely
ded
Luke pointed out that we should not be inserting extraneous data into the
blockchain, so this sounds like the best option, Eric.
I'm under the impression that a Bitcoin user Alice cannot see the actual public
key of Bitcoin user Bob, so if we had Hive store metadata on a server relating
to a g
The current version requires a signed cert yes. Whether that's difficult or
not depends on the policies of the cert authorities. Ultimately all they
have to do is verify an email address by sending it a clickable link, which
is why StartSSL do it for free. Probably they aren't optimised for
usabili
OK, I was under the impression that this was mostly developed for merchants.
I've seen some discussion here that seemed to suggest it requiring some
non-trivial (for an end user) steps like getting a CA-signed certificate.
-wendell
grabhive.com | twitter.com/grabhive | gpg: 6C0C9411
On Sep 7,
This is the sort of thing the payment protocol is for. The recipient would
vend a PaymentRequest containing identity details. The sender would submit
a Payment containing his/hers. The wallet then understands what to do.
On Fri, Sep 6, 2013 at 5:07 PM, Wendell wrote:
> Hi all,
>
> We're thinkin
Why not just use the transaction hash itself for the lookup? Also, presumably
you'd want to encrypt the data so that only the recipient of the transaction
can do this lookup.
-Eric
On Sep 6, 2013, at 8:07 AM, Wendell wrote:
> Hi all,
>
> We're thinking about ways of automatically exchanging
Hi all,
We're thinking about ways of automatically exchanging contact details between
wallets, in order to encourage the proliferation of identifiable names and
photos rather than long and hard-to-verify addresses.
The simplest version goes like this:
2 BTC Bitcoin is sent to someone, and a da
10 matches
Mail list logo
