📅 Original date posted:2013-09-17
📝 Original message: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 at 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
Wendell [ARCHIVE] /
npub1c5…34kvp
2023-06-07 15:06:38
in reply to nevent1q…ycs0
Author Public Key
npub1c56tk56u5846gc9tj6kcd886y9sztx6yrj24zhegrsv87qfs7nes834kvpPublished at
2023-06-07 15:06:38Event JSON
{
"id": "c4792176d50f04a32844aff87b0e2671088cc5be23b494f20f4e99ae8ede918b",
"pubkey": "c534bb535ca1eba460ab96ad869cfa2160259b441c95515f281c187f0130f4f3",
"created_at": 1686150398,
"kind": 1,
"tags": [
[
"e",
"81353ffadfcedef76e290d10f50e6602d23d96b23fcfba53fc07623cddfe7e57",
"",
"root"
],
[
"e",
"cc642312d185146a6e607ada6a2ac307fcb8e6df459996b7ebf87eaafa931333",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 Original date posted:2013-09-17\n📝 Original message:Thanks Mike.\n\nI 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?\n\n-wendell\n\ngrabhive.com | twitter.com/grabhive | gpg: 6C0C9411\n\nOn Sep 17, 2013, at 12:03 PM, Mike Hearn wrote:\n\n\u003e 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.\n\u003e \n\u003e 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.\n\u003e \n\u003e\u003e On Tue, Sep 17, 2013 at 11:30 AM, Wendell \u003cw at grabhive.com\u003e wrote:\n\u003e\u003e Couple of things I just thought about:\n\u003e\u003e \n\u003e\u003e 1- Presume server should only sweep with two (or more, see below) revocation certificates being present\n\u003e\u003e 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?).\n\u003e\u003e \n\u003e\u003e 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!\n\u003e\u003e \n\u003e\u003e 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.\n\u003e\u003e \n\u003e\u003e -wendell\n\u003e\u003e \n\u003e\u003e grabhive.com | twitter.com/grabhive | gpg: 6C0C9411",
"sig": "e99b7a81857255ac094ef75b7b222e2d7a0e94f062ef5d94f3fb33fd6fd8aa86dda7c91ddba12b95e54940f83ac4f840c69ee693da6dd81aa92e3772b2c7181a"
}