Stephen Pair [ARCHIVE] on Nostr: š Original date posted:2012-12-20 š Original message:On Thu, Dec 20, 2012 at ...
š
Original date posted:2012-12-20
š Original message:On Thu, Dec 20, 2012 at 12:43 PM, Mike Hearn <mike at plan99.net> wrote:
> > 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.
No, it's not a killer...just a hassle. JSON is convenient and ubiquitous
and there is something to be said for that (and I wanted to point out that
the JOSE objection was invalid). Protobufs are nice and efficient, but who
cares. You're talking about direct communications rather than something
that will be bounced around every node in the mesh network. I don't really
care much either way, it's not worth debating. I'm just thankful no one is
arguing for XML or IIOP. :)
> ...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.
>
This leaves too much to chance for my taste. Forget email, what about
jabber, ICQ, skype, IRC? Email is just one communications medium, there
are many others for which there would be no assurance that the payment
request hasn't been tampered with. You could at a minimum allow a person
to create a normal ECC key, but have it used as an identity in
communications rather than a payment address. You store it in a separate
file in ~/.bitcoin/id ...you don't have to solve the whole set of PKI
problems, people could exchange identities using any secure channel they
are comfortable with (email + phone verification of a short hash id would
be sufficient). In another scenario, an id could be made available over
https, using the normal SSL certificate and CA infrastructure to verify
authenticity. This way all messages could be signed and/or encrypted
without the user having to go out of their way to use external tools or
infrastructure that is often not very user friendly. You also need
encryption for the "cheque" feature...asking people to use GPG would be too
much of a burden (and email DKIM doesn't offer encryption).
>>> wandering off topic >>>
Indeed, "cheques" could become the dominant method of person to person
payments...first, you would obtain someone's id, which you might already
have on file (rather than obtaining a bitcoin address), then you would
generate a "cheque" for the amount desired and send it to them...the
recipient then has full control over what address they want to sweep the
funds to as well as whether they'd like to include a miner fee to speed the
confirmation along. Despite the fact that you may send many payments to the
same identity, the only thing showing up on the p2p network and the block
chain is the one time use address for the cheque and the recipient's wallet
address. This means the recipient has much more control over the address
policy used (compared with simply giving out a bitcoin address that may be
reused).
<<<
> 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.
>
I know, but as I was responding, I began to realize this is a mistake.
It's worthwhile to tackle that problem first...if done right, it would pay
huge dividends. Also, identity is one thing, an elaborate trust based
identity verification system (like CA's) is a whole other thing. I think
the former is pretty simple actually...and it's all that's really needed
for the time being (as I alluded, a bitcoin identity could be communicated
or verified using the existing X.509/CA infrastructure if desired...you
could also use the PGP infrastructure).
> > 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.
Actually, I was speaking more in terms of relying on the address to match
up a transaction to an invoice. The merchant_data field frees you from
having to do that.
> 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.
>
Yeah, that's neat...I hadn't thought of that possibility.
> > 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.
>
It's not a big deal, I just think a referential model is more general than
embedding objects within each other.
> > 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.
>
Ah, I see it was renamed PaymentACK...the point of signing a PaymentACK is
that while you could prove that you paid according to a PaymentRequest, a
signed PaymentACK is proof that the recipient acknowledged you have made
that payment.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20121220/4ba9c584/attachment.html>;
š Original message:On Thu, Dec 20, 2012 at 12:43 PM, Mike Hearn <mike at plan99.net> wrote:
> > 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.
No, it's not a killer...just a hassle. JSON is convenient and ubiquitous
and there is something to be said for that (and I wanted to point out that
the JOSE objection was invalid). Protobufs are nice and efficient, but who
cares. You're talking about direct communications rather than something
that will be bounced around every node in the mesh network. I don't really
care much either way, it's not worth debating. I'm just thankful no one is
arguing for XML or IIOP. :)
> ...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.
>
This leaves too much to chance for my taste. Forget email, what about
jabber, ICQ, skype, IRC? Email is just one communications medium, there
are many others for which there would be no assurance that the payment
request hasn't been tampered with. You could at a minimum allow a person
to create a normal ECC key, but have it used as an identity in
communications rather than a payment address. You store it in a separate
file in ~/.bitcoin/id ...you don't have to solve the whole set of PKI
problems, people could exchange identities using any secure channel they
are comfortable with (email + phone verification of a short hash id would
be sufficient). In another scenario, an id could be made available over
https, using the normal SSL certificate and CA infrastructure to verify
authenticity. This way all messages could be signed and/or encrypted
without the user having to go out of their way to use external tools or
infrastructure that is often not very user friendly. You also need
encryption for the "cheque" feature...asking people to use GPG would be too
much of a burden (and email DKIM doesn't offer encryption).
>>> wandering off topic >>>
Indeed, "cheques" could become the dominant method of person to person
payments...first, you would obtain someone's id, which you might already
have on file (rather than obtaining a bitcoin address), then you would
generate a "cheque" for the amount desired and send it to them...the
recipient then has full control over what address they want to sweep the
funds to as well as whether they'd like to include a miner fee to speed the
confirmation along. Despite the fact that you may send many payments to the
same identity, the only thing showing up on the p2p network and the block
chain is the one time use address for the cheque and the recipient's wallet
address. This means the recipient has much more control over the address
policy used (compared with simply giving out a bitcoin address that may be
reused).
<<<
> 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.
>
I know, but as I was responding, I began to realize this is a mistake.
It's worthwhile to tackle that problem first...if done right, it would pay
huge dividends. Also, identity is one thing, an elaborate trust based
identity verification system (like CA's) is a whole other thing. I think
the former is pretty simple actually...and it's all that's really needed
for the time being (as I alluded, a bitcoin identity could be communicated
or verified using the existing X.509/CA infrastructure if desired...you
could also use the PGP infrastructure).
> > 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.
Actually, I was speaking more in terms of relying on the address to match
up a transaction to an invoice. The merchant_data field frees you from
having to do that.
> 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.
>
Yeah, that's neat...I hadn't thought of that possibility.
> > 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.
>
It's not a big deal, I just think a referential model is more general than
embedding objects within each other.
> > 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.
>
Ah, I see it was renamed PaymentACK...the point of signing a PaymentACK is
that while you could prove that you paid according to a PaymentRequest, a
signed PaymentACK is proof that the recipient acknowledged you have made
that payment.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20121220/4ba9c584/attachment.html>;