📅 Original date posted:2012-12-20
📝 Original message:Thanks for the thoughts. For those who don't know, Stephen works for BitPay.
> My first observation is that the proposal is too heavily oriented around a
> merchant/customer interaction.
The term "merchant" is just being used to mean the entity requesting
the payment. I'm hopeful that in future mobile wallets will be
creating these messages where today they'd make URLs and QRcodes. So
it's definitely intended for person to person payments too.
> you may find yourself in a situation needing to parse a protobuf
> message in a web browser
Nothing stops you converting them into whatever form you want on the
server side. If you don't care about the signature checking then it's
no problem to use a server. If you do then you'd need to ship all the
code for verifying signatures that to the client anyway, at which
point a small protobuf parser is hardly a deal killer.
> ...like what about the casual user that wants to create a payment request to
> send to their friend over email
They can send an unsigned payment request. Note that if you mail it as
an attachment from a competent, up to date email provider then the
attachment isn't really unsigned. The whole thing is covered by the
emails DKIM signature which is applied transparently by the ESP. If
the signature fails to verify then the mail client can show that or
treat the mail differently (as Gmail does). This is easy to use for
the end user - they don't have to think about cryptography or PKI. As
long as their email account is secure then they can send signed mails
asserting to their identity.
> Refund addresses...this is not going to be as useful as people might
> think...most refunds that bitpay needs to process happen days or even months
> after the initial purchase
Useful feedback, thanks. Still, there may be other types of merchants
for whom it's useful, and many users won't change their wallet. It
certainly simplifies things if you can present the refund address and
give a one-click option to use it. If the user wants to use a
different address, then they can go onto the slow/complicated path.
This current spec deliberately punts on the topic of identifying end
users. It's a difficult problem. Whereas many merchants have SSL
certs, most end users don't have published keys in any useful form. By
far the easiest way for 99% of people to generate a signed message is
to send email that's signed by DKIM (from gmail, hotmail, yahoo, other
providers etc). Then it's all transparent and behind the scenes. Their
identity is their email address.
So for BitPays scenario, you could require an email to be sent by the
end user containing new instructions. Your MTA can show you whether
the mail is correctly DKIM signed or not when deciding whether to
follow the instructions.
> But, if the recipient never cashes the check, the sender could pull those
> funds back after a certain period of time.
Yeah, I like the term "check"/"cheque" for that concept of a reversible payment.
> I like the use of merchant_data...this means that you no longer will need a
> unique bitcoin address for every invoice.
It's still a good idea to use one for privacy reasons. The merchant
data is there so you can stuff whatever state you want into it. So
it's like cookies. You don't have to keep state on the server side.
Just encrypt/sign it, put it in the invoice, and when you get a
payment message back there's no need to do database lookups or
anything, you can just do some crypto and know who is submitting it.
> Generally speaking, I'm not a fan of embedding things like that
What's wrong with it? Isn't your proposal more complex? I don't see
why it's better than just embedding it.
> The Receipt should be signed...it could be used as proof of payment by
> wallets.
There's no Receipt message, a SignedPaymentRequest + transactions that
pay to the requested outputs are together the proof of payment.
Re a new URI scheme. Interesting idea, thanks for the suggestion. It
seemed like it'd be easier for merchants to integrate if a single
linked worked for all wallet implementations/versions. But I guess we
could do both schemes, even.
Mike Hearn [ARCHIVE] /
npub17t…4qgyd
2023-06-07 10:43:22
in reply to nevent1q…aals
Author Public Key
npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydPublished at
2023-06-07 10:43:22Event JSON
{
"id": "e69c29ec2e95587812e52589481ee61ea5b72459e6908378cbd6cac18fe96b2e",
"pubkey": "f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2",
"created_at": 1686134602,
"kind": 1,
"tags": [
[
"e",
"1bd78b419247dfb60fa2e8b1cf4983b406411160c7aa6e19780a4034c5da34de",
"",
"root"
],
[
"e",
"fb274479c040b83a0db4b2cfa82f42825fab4f33734f2a5d2413b7e7224fce5c",
"",
"reply"
],
[
"p",
"5570d204bda7735652416863ba13b26e8065a443c269cdcedef82e8107dc93a7"
]
],
"content": "📅 Original date posted:2012-12-20\n📝 Original message:Thanks for the thoughts. For those who don't know, Stephen works for BitPay.\n\n\u003e My first observation is that the proposal is too heavily oriented around a\n\u003e merchant/customer interaction.\n\nThe term \"merchant\" is just being used to mean the entity requesting\nthe payment. I'm hopeful that in future mobile wallets will be\ncreating these messages where today they'd make URLs and QRcodes. So\nit's definitely intended for person to person payments too.\n\n\u003e you may find yourself in a situation needing to parse a protobuf\n\u003e message in a web browser\n\nNothing stops you converting them into whatever form you want on the\nserver side. If you don't care about the signature checking then it's\nno problem to use a server. If you do then you'd need to ship all the\ncode for verifying signatures that to the client anyway, at which\npoint a small protobuf parser is hardly a deal killer.\n\n\u003e ...like what about the casual user that wants to create a payment request to\n\u003e send to their friend over email\n\nThey can send an unsigned payment request. Note that if you mail it as\nan attachment from a competent, up to date email provider then the\nattachment isn't really unsigned. The whole thing is covered by the\nemails DKIM signature which is applied transparently by the ESP. If\nthe signature fails to verify then the mail client can show that or\ntreat the mail differently (as Gmail does). This is easy to use for\nthe end user - they don't have to think about cryptography or PKI. As\nlong as their email account is secure then they can send signed mails\nasserting to their identity.\n\n\u003e Refund addresses...this is not going to be as useful as people might\n\u003e think...most refunds that bitpay needs to process happen days or even months\n\u003e after the initial purchase\n\nUseful feedback, thanks. Still, there may be other types of merchants\nfor whom it's useful, and many users won't change their wallet. It\ncertainly simplifies things if you can present the refund address and\ngive a one-click option to use it. If the user wants to use a\ndifferent address, then they can go onto the slow/complicated path.\n\nThis current spec deliberately punts on the topic of identifying end\nusers. It's a difficult problem. Whereas many merchants have SSL\ncerts, most end users don't have published keys in any useful form. By\nfar the easiest way for 99% of people to generate a signed message is\nto send email that's signed by DKIM (from gmail, hotmail, yahoo, other\nproviders etc). Then it's all transparent and behind the scenes. Their\nidentity is their email address.\n\nSo for BitPays scenario, you could require an email to be sent by the\nend user containing new instructions. Your MTA can show you whether\nthe mail is correctly DKIM signed or not when deciding whether to\nfollow the instructions.\n\n\u003e But, if the recipient never cashes the check, the sender could pull those\n\u003e funds back after a certain period of time.\n\nYeah, I like the term \"check\"/\"cheque\" for that concept of a reversible payment.\n\n\u003e I like the use of merchant_data...this means that you no longer will need a\n\u003e unique bitcoin address for every invoice.\n\nIt's still a good idea to use one for privacy reasons. The merchant\ndata is there so you can stuff whatever state you want into it. So\nit's like cookies. You don't have to keep state on the server side.\nJust encrypt/sign it, put it in the invoice, and when you get a\npayment message back there's no need to do database lookups or\nanything, you can just do some crypto and know who is submitting it.\n\n\u003e Generally speaking, I'm not a fan of embedding things like that\n\nWhat's wrong with it? Isn't your proposal more complex? I don't see\nwhy it's better than just embedding it.\n\n\u003e The Receipt should be signed...it could be used as proof of payment by\n\u003e wallets.\n\nThere's no Receipt message, a SignedPaymentRequest + transactions that\npay to the requested outputs are together the proof of payment.\n\nRe a new URI scheme. Interesting idea, thanks for the suggestion. It\nseemed like it'd be easier for merchants to integrate if a single\nlinked worked for all wallet implementations/versions. But I guess we\ncould do both schemes, even.",
"sig": "eb7cb1735777d263d02ef99a060c38cade7e3a42a4321263ebe5d873463911f9d74081274b554739e2d1eb7a52ebed093403ee216edd754578bca2fb6e325e4e"
}