* [Bitcoin-development] Simple contacts exchange (was: Social network integration (brainstorm))
@ 2013-09-06 15:07 Wendell
2013-09-06 22:47 ` Eric Lombrozo
2013-09-07 21:44 ` Mike Hearn
0 siblings, 2 replies; 10+ messages in thread
From: Wendell @ 2013-09-06 15:07 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1028 bytes --]
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 data lookup hash is inserted into the transaction. When it arrives on the other end, it is indeed looked up, and instead of being presented with a dialogue that says "you received 2 BTC from 13Y94z43Nbbb6wevRyk82CeDoYQ5S28zmA", it's "You received 2 BTC from Frank Jones" including a nice photo.
Now. We can simply delete this data in reference to the transaction ID after it happens (or delete it after a time), but is there any more decentralized way to do it? I would prefer us to run no dedicated servers that would ever put us in a position of being coerced into giving data, or otherwise altering our system to store it.
Any thoughts about this?
-wendell
grabhive.com | twitter.com/grabhive | gpg: 6C0C9411
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 841 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] Simple contacts exchange (was: Social network integration (brainstorm))
2013-09-06 15:07 [Bitcoin-development] Simple contacts exchange (was: Social network integration (brainstorm)) Wendell
@ 2013-09-06 22:47 ` Eric Lombrozo
2013-09-16 14:05 ` Wendell
2013-09-07 21:44 ` Mike Hearn
1 sibling, 1 reply; 10+ messages in thread
From: Eric Lombrozo @ 2013-09-06 22:47 UTC (permalink / raw)
To: Wendell; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1960 bytes --]
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 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 data lookup hash is inserted into the transaction. When it arrives on the other end, it is indeed looked up, and instead of being presented with a dialogue that says "you received 2 BTC from 13Y94z43Nbbb6wevRyk82CeDoYQ5S28zmA", it's "You received 2 BTC from Frank Jones" including a nice photo.
>
> Now. We can simply delete this data in reference to the transaction ID after it happens (or delete it after a time), but is there any more decentralized way to do it? I would prefer us to run no dedicated servers that would ever put us in a position of being coerced into giving data, or otherwise altering our system to store it.
>
> Any thoughts about this?
>
> -wendell
>
> grabhive.com | twitter.com/grabhive | gpg: 6C0C9411
>
> ------------------------------------------------------------------------------
> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> Discover the easy way to master current and previous Microsoft technologies
> and advance your career. Get an incredible 1,500+ hours of step-by-step
> tutorial videos with LearnDevNow. Subscribe today and save!
> http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] Simple contacts exchange (was: Social network integration (brainstorm))
2013-09-06 15:07 [Bitcoin-development] Simple contacts exchange (was: Social network integration (brainstorm)) Wendell
2013-09-06 22:47 ` Eric Lombrozo
@ 2013-09-07 21:44 ` Mike Hearn
2013-09-09 7:26 ` Wendell
1 sibling, 1 reply; 10+ messages in thread
From: Mike Hearn @ 2013-09-07 21:44 UTC (permalink / raw)
To: Wendell; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1994 bytes --]
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 <w@grabhive•com> wrote:
> 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 data lookup hash is inserted into
> the transaction. When it arrives on the other end, it is indeed looked up,
> and instead of being presented with a dialogue that says "you received 2
> BTC from 13Y94z43Nbbb6wevRyk82CeDoYQ5S28zmA", it's "You received 2 BTC from
> Frank Jones" including a nice photo.
>
> Now. We can simply delete this data in reference to the transaction ID
> after it happens (or delete it after a time), but is there any more
> decentralized way to do it? I would prefer us to run no dedicated servers
> that would ever put us in a position of being coerced into giving data, or
> otherwise altering our system to store it.
>
> Any thoughts about this?
>
> -wendell
>
> grabhive.com | twitter.com/grabhive | gpg: 6C0C9411
>
>
>
> ------------------------------------------------------------------------------
> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> Discover the easy way to master current and previous Microsoft technologies
> and advance your career. Get an incredible 1,500+ hours of step-by-step
> tutorial videos with LearnDevNow. Subscribe today and save!
> http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
[-- Attachment #2: Type: text/html, Size: 2768 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] Simple contacts exchange (was: Social network integration (brainstorm))
2013-09-07 21:44 ` Mike Hearn
@ 2013-09-09 7:26 ` Wendell
2013-09-09 11:43 ` Mike Hearn
0 siblings, 1 reply; 10+ messages in thread
From: Wendell @ 2013-09-09 7:26 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev
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, 2013, at 11:44 PM, Mike Hearn wrote:
> 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] Simple contacts exchange (was: Social network integration (brainstorm))
2013-09-09 7:26 ` Wendell
@ 2013-09-09 11:43 ` Mike Hearn
0 siblings, 0 replies; 10+ messages in thread
From: Mike Hearn @ 2013-09-09 11:43 UTC (permalink / raw)
To: Wendell; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1330 bytes --]
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
usability, but there's no technical reason why one couldn't be. It's a
competitive market, after all.
There's also the option of extending the payment protocol to support other
forms of PKI. But from a technical perspective the X.509 PKI is fine.
Someone can always set up their own CA for the Bitcoin community and
convince wallet developers to include their root cert, after all.
On Mon, Sep 9, 2013 at 9:26 AM, Wendell <w@grabhive•com> wrote:
> 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, 2013, at 11:44 PM, Mike Hearn wrote:
>
> > 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.
>
>
[-- Attachment #2: Type: text/html, Size: 1893 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] Simple contacts exchange (was: Social network integration (brainstorm))
2013-09-06 22:47 ` Eric Lombrozo
@ 2013-09-16 14:05 ` Wendell
2013-09-17 9:30 ` Wendell
0 siblings, 1 reply; 10+ messages in thread
From: Wendell @ 2013-09-16 14:05 UTC (permalink / raw)
To: Eric Lombrozo; +Cc: Bitcoin Dev
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 given transaction ID, I would not be able to use those public keys key to encrypt. Is this a misunderstanding or is it correct?
Assuming it is correct, the best that I could come up with was storing the transaction ID with a _fresh_ public key on a server, each time a transfer is made. Altogether it looks like this:
- Alice generates a new keypair & revocation certificate for the transaction
- Alice makes a Bitcoin transaction to Bob
- Alice sends the transaction ID plus the new public key to server
- Bob receives the Bitcoin transaction
- Bob generates a new keypair & revocation certificate
- Bob does a transaction ID lookup on the server, receives Alice's public key, sends his own new one
- Bob encrypts his user metadata against Alice's new key
- Alice downloads and decrypts Bob's metadata
- Alice uploads her revocation certificate
- Alice uploads her own metadata
- Bob downloads Alice's metadata
- Bob uploads his revocation certificate
- (Server removes all keys with revocation certificates)
I presume going the extra mile to generate new keys for each transaction is helpful for privacy?
The above seems rather inelegant to me. I really don't like that clients (wallets) are going to be beating down the server all the time checking for keys, or that there is a possibility of a desynchronization so severe that the user receives the data much too late for it to be useful. But, I suppose it can work.
Another thing I'm considering is Alice/Bob validating each other. I suppose we should include some kind of code that we encourage people to read to each other over the phone or some other medium, to ensure that "it really is Alice", before (for example) returning money to a very legit-looking personage.
Any other thoughts? I would love to do this without using any servers at all ("serverless keyserver", anyone?), but I am not quite sure how.
-wendell
grabhive.com | twitter.com/grabhive | gpg: 6C0C9411
On Sep 7, 2013, at 12:47 AM, Eric Lombrozo wrote:
> 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 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 data lookup hash is inserted into the transaction. When it arrives on the other end, it is indeed looked up, and instead of being presented with a dialogue that says "you received 2 BTC from 13Y94z43Nbbb6wevRyk82CeDoYQ5S28zmA", it's "You received 2 BTC from Frank Jones" including a nice photo.
>>
>> Now. We can simply delete this data in reference to the transaction ID after it happens (or delete it after a time), but is there any more decentralized way to do it? I would prefer us to run no dedicated servers that would ever put us in a position of being coerced into giving data, or otherwise altering our system to store it.
>>
>> Any thoughts about this?
>>
>> -wendell
>>
>> grabhive.com | twitter.com/grabhive | gpg: 6C0C9411
>>
>> ------------------------------------------------------------------------------
>> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
>> Discover the easy way to master current and previous Microsoft technologies
>> and advance your career. Get an incredible 1,500+ hours of step-by-step
>> tutorial videos with LearnDevNow. Subscribe today and save!
>> http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk_______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists•sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] Simple contacts exchange (was: Social network integration (brainstorm))
2013-09-16 14:05 ` Wendell
@ 2013-09-17 9:30 ` Wendell
2013-09-17 10:03 ` Mike Hearn
0 siblings, 1 reply; 10+ messages in thread
From: Wendell @ 2013-09-17 9:30 UTC (permalink / raw)
To: Eric Lombrozo; +Cc: Bitcoin Dev
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 dedicated attacker with a fast connection?).
Is there a way to do #2 without creating yet another transaction? Admittedly I am still really puzzled about the accessibility of public keys in Bitcoin!
Please remember that the idea is to have two wallets securely exchange a packet of metadata about a transaction beyond the scope of Bitcoin itself (a name, perhaps a small photo, etc) in order to increase usability. This will be my last post here on the topic except to reply in case anyone else contributes.
-wendell
grabhive.com | twitter.com/grabhive | gpg: 6C0C9411
On Sep 16, 2013, at 4:05 PM, Wendell wrote:
> 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 given transaction ID, I would not be able to use those public keys key to encrypt. Is this a misunderstanding or is it correct?
>
> Assuming it is correct, the best that I could come up with was storing the transaction ID with a _fresh_ public key on a server, each time a transfer is made. Altogether it looks like this:
>
> - Alice generates a new keypair & revocation certificate for the transaction
> - Alice makes a Bitcoin transaction to Bob
> - Alice sends the transaction ID plus the new public key to server
> - Bob receives the Bitcoin transaction
> - Bob generates a new keypair & revocation certificate
> - Bob does a transaction ID lookup on the server, receives Alice's public key, sends his own new one
> - Bob encrypts his user metadata against Alice's new key
> - Alice downloads and decrypts Bob's metadata
> - Alice uploads her revocation certificate
> - Alice uploads her own metadata
> - Bob downloads Alice's metadata
> - Bob uploads his revocation certificate
> - (Server removes all keys with revocation certificates)
>
> I presume going the extra mile to generate new keys for each transaction is helpful for privacy?
>
> The above seems rather inelegant to me. I really don't like that clients (wallets) are going to be beating down the server all the time checking for keys, or that there is a possibility of a desynchronization so severe that the user receives the data much too late for it to be useful. But, I suppose it can work.
>
> Another thing I'm considering is Alice/Bob validating each other. I suppose we should include some kind of code that we encourage people to read to each other over the phone or some other medium, to ensure that "it really is Alice", before (for example) returning money to a very legit-looking personage.
>
> Any other thoughts? I would love to do this without using any servers at all ("serverless keyserver", anyone?), but I am not quite sure how.
>
> -wendell
>
> grabhive.com | twitter.com/grabhive | gpg: 6C0C9411
>
> On Sep 7, 2013, at 12:47 AM, Eric Lombrozo wrote:
>
>> 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 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 data lookup hash is inserted into the transaction. When it arrives on the other end, it is indeed looked up, and instead of being presented with a dialogue that says "you received 2 BTC from 13Y94z43Nbbb6wevRyk82CeDoYQ5S28zmA", it's "You received 2 BTC from Frank Jones" including a nice photo.
>>>
>>> Now. We can simply delete this data in reference to the transaction ID after it happens (or delete it after a time), but is there any more decentralized way to do it? I would prefer us to run no dedicated servers that would ever put us in a position of being coerced into giving data, or otherwise altering our system to store it.
>>>
>>> Any thoughts about this?
>>>
>>> -wendell
>>>
>>> grabhive.com | twitter.com/grabhive | gpg: 6C0C9411
>>>
>>> ------------------------------------------------------------------------------
>>> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
>>> Discover the easy way to master current and previous Microsoft technologies
>>> and advance your career. Get an incredible 1,500+ hours of step-by-step
>>> tutorial videos with LearnDevNow. Subscribe today and save!
>>> http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk_______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists•sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] Simple contacts exchange (was: Social network integration (brainstorm))
2013-09-17 9:30 ` Wendell
@ 2013-09-17 10:03 ` Mike Hearn
2013-09-17 12:05 ` Wendell
0 siblings, 1 reply; 10+ messages in thread
From: Mike Hearn @ 2013-09-17 10:03 UTC (permalink / raw)
To: Wendell; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 6598 bytes --]
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 extended the payment protocol to include
information about the person who generated it.
On Tue, Sep 17, 2013 at 11:30 AM, Wendell <w@grabhive•com> wrote:
> 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
> dedicated attacker with a fast connection?).
>
> Is there a way to do #2 without creating yet another transaction?
> Admittedly I am still really puzzled about the accessibility of public keys
> in Bitcoin!
>
> Please remember that the idea is to have two wallets securely exchange a
> packet of metadata about a transaction beyond the scope of Bitcoin itself
> (a name, perhaps a small photo, etc) in order to increase usability. This
> will be my last post here on the topic except to reply in case anyone else
> contributes.
>
> -wendell
>
> grabhive.com | twitter.com/grabhive | gpg: 6C0C9411
>
> On Sep 16, 2013, at 4:05 PM, Wendell wrote:
>
> > 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 given transaction ID, I would not be able to use those
> public keys key to encrypt. Is this a misunderstanding or is it correct?
> >
> > Assuming it is correct, the best that I could come up with was storing
> the transaction ID with a _fresh_ public key on a server, each time a
> transfer is made. Altogether it looks like this:
> >
> > - Alice generates a new keypair & revocation certificate for the
> transaction
> > - Alice makes a Bitcoin transaction to Bob
> > - Alice sends the transaction ID plus the new public key to server
> > - Bob receives the Bitcoin transaction
> > - Bob generates a new keypair & revocation certificate
> > - Bob does a transaction ID lookup on the server, receives Alice's
> public key, sends his own new one
> > - Bob encrypts his user metadata against Alice's new key
> > - Alice downloads and decrypts Bob's metadata
> > - Alice uploads her revocation certificate
> > - Alice uploads her own metadata
> > - Bob downloads Alice's metadata
> > - Bob uploads his revocation certificate
> > - (Server removes all keys with revocation certificates)
> >
> > I presume going the extra mile to generate new keys for each transaction
> is helpful for privacy?
> >
> > The above seems rather inelegant to me. I really don't like that clients
> (wallets) are going to be beating down the server all the time checking for
> keys, or that there is a possibility of a desynchronization so severe that
> the user receives the data much too late for it to be useful. But, I
> suppose it can work.
> >
> > Another thing I'm considering is Alice/Bob validating each other. I
> suppose we should include some kind of code that we encourage people to
> read to each other over the phone or some other medium, to ensure that "it
> really is Alice", before (for example) returning money to a very
> legit-looking personage.
> >
> > Any other thoughts? I would love to do this without using any servers at
> all ("serverless keyserver", anyone?), but I am not quite sure how.
> >
> > -wendell
> >
> > grabhive.com | twitter.com/grabhive | gpg: 6C0C9411
> >
> > On Sep 7, 2013, at 12:47 AM, Eric Lombrozo wrote:
> >
> >> 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 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 data lookup hash is inserted
> into the transaction. When it arrives on the other end, it is indeed looked
> up, and instead of being presented with a dialogue that says "you received
> 2 BTC from 13Y94z43Nbbb6wevRyk82CeDoYQ5S28zmA", it's "You received 2 BTC
> from Frank Jones" including a nice photo.
> >>>
> >>> Now. We can simply delete this data in reference to the transaction ID
> after it happens (or delete it after a time), but is there any more
> decentralized way to do it? I would prefer us to run no dedicated servers
> that would ever put us in a position of being coerced into giving data, or
> otherwise altering our system to store it.
> >>>
> >>> Any thoughts about this?
> >>>
> >>> -wendell
> >>>
> >>> grabhive.com | twitter.com/grabhive | gpg: 6C0C9411
> >>>
> >>>
> ------------------------------------------------------------------------------
> >>> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> >>> Discover the easy way to master current and previous Microsoft
> technologies
> >>> and advance your career. Get an incredible 1,500+ hours of step-by-step
> >>> tutorial videos with LearnDevNow. Subscribe today and save!
> >>>
> http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk_______________________________________________
> >>> Bitcoin-development mailing list
> >>> Bitcoin-development@lists•sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
> LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
> 1,500+ hours of tutorials including VisualStudio 2012, Windows 8,
> SharePoint
> 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack
> includes
> Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
> http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
[-- Attachment #2: Type: text/html, Size: 8618 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] Simple contacts exchange (was: Social network integration (brainstorm))
2013-09-17 10:03 ` Mike Hearn
@ 2013-09-17 12:05 ` Wendell
2013-09-17 12:36 ` Mike Hearn
0 siblings, 1 reply; 10+ messages in thread
From: Wendell @ 2013-09-17 12:05 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev
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 that I understand _why_ signed certificates are even required. Isn't that likely be an obstacle to adoption for use cases like this?
-wendell
grabhive.com | twitter.com/grabhive | gpg: 6C0C9411
On Sep 17, 2013, at 12:03 PM, Mike Hearn wrote:
> 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 extended the payment protocol to include information about the person who generated it.
>
>> On Tue, Sep 17, 2013 at 11:30 AM, Wendell <w@grabhive•com> wrote:
>> 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 dedicated attacker with a fast connection?).
>>
>> Is there a way to do #2 without creating yet another transaction? Admittedly I am still really puzzled about the accessibility of public keys in Bitcoin!
>>
>> Please remember that the idea is to have two wallets securely exchange a packet of metadata about a transaction beyond the scope of Bitcoin itself (a name, perhaps a small photo, etc) in order to increase usability. This will be my last post here on the topic except to reply in case anyone else contributes.
>>
>> -wendell
>>
>> grabhive.com | twitter.com/grabhive | gpg: 6C0C9411
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] Simple contacts exchange (was: Social network integration (brainstorm))
2013-09-17 12:05 ` Wendell
@ 2013-09-17 12:36 ` Mike Hearn
0 siblings, 0 replies; 10+ messages in thread
From: Mike Hearn @ 2013-09-17 12:36 UTC (permalink / raw)
To: Wendell; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 263 bytes --]
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?
[-- Attachment #2: Type: text/html, Size: 340 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2013-09-17 12:58 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-09-06 15:07 [Bitcoin-development] Simple contacts exchange (was: Social network integration (brainstorm)) Wendell
2013-09-06 22:47 ` Eric Lombrozo
2013-09-16 14:05 ` Wendell
2013-09-17 9:30 ` Wendell
2013-09-17 10:03 ` Mike Hearn
2013-09-17 12:05 ` Wendell
2013-09-17 12:36 ` Mike Hearn
2013-09-07 21:44 ` Mike Hearn
2013-09-09 7:26 ` Wendell
2013-09-09 11:43 ` Mike Hearn
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox