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
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?
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
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
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,
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
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 w...@grabhive.com wrote:
Hi all,
We're thinking about ways of
7 matches
Mail list logo
